I'm trying to install cairo (on my way to installing graph viz) using darwinports on a Mac G4. OS is 10.4.11. I get cairo-quartz-image-surface.c:69: error: 'kCGBitmapByteOrder32Host' undeclared while it's compiling. I've pasted in the whole listing. Thanks for looking into this bug. It's stalling a project. Dave ---- david-walends-powerbook-g4-17:~/projects/jdigraph/v2/source/uber dwalend$ sudo port install cairo ---> Building cairo with target all Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_cairo/work/cairo-1.6.4" && make all " returned error 2 Command output: make all-recursive Making all in src /bin/sh ../libtool --tag=CC --mode=compile /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include -I. -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include -I/opt/local/include/libpng12 -DXTHREADS -I/opt/local/include -I/usr/X11R6/include -I/usr/X11R6/include -I/opt/local/include/pixman-1 -Wall -Wextra -Wsign-compare -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wstrict-aliasing=2 -Winit-self -Wdeclaration-after-statement -Wold-style-definition -Wno-missing-field-initializers -Wno-unused-parameter -Wno-long-long -Winline -fno-strict-aliasing -O2 -MT libcairo_la-cairo-quartz-image-surface.lo -MD -MP -MF .deps/libcairo_la-cairo-quartz-image-surface.Tpo -c -o libcairo_la-cairo-quartz-image-surface.lo `test -f 'cairo-quartz-image-surface.c' || echo './'`cairo-quartz-image-surface.c /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include -I. -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include -I/opt/local/include/libpng12 -DXTHREADS -I/opt/local/include -I/usr/X11R6/include -I/usr/X11R6/include -I/opt/local/include/pixman-1 -Wall -Wextra -Wsign-compare -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wstrict-aliasing=2 -Winit-self -Wdeclaration-after-statement -Wold-style-definition -Wno-missing-field-initializers -Wno-unused-parameter -Wno-long-long -Winline -fno-strict-aliasing -O2 -MT libcairo_la-cairo-quartz-image-surface.lo -MD -MP -MF .deps/libcairo_la-cairo-quartz-image-surface.Tpo -c cairo-quartz-image-surface.c -fno-common -DPIC -o .libs/libcairo_la-cairo-quartz-image-surface.o cairo-quartz-image-surface.c: In function '_cairo_quartz_create_cgimage': cairo-quartz-image-surface.c:69: error: 'kCGBitmapByteOrder32Host' undeclared (first use in this function) cairo-quartz-image-surface.c:69: error: (Each undeclared identifier is reported only once cairo-quartz-image-surface.c:69: error: for each function it appears in.) make[2]: *** [libcairo_la-cairo-quartz-image-surface.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error: Status 1 encountered during processing.
This problem was also reported on the cairo mailing list in April 2008: http://lists.freedesktop.org/archives/cairo/2008-April/013904.html A workaround is proposed there (define kCGBitmapByteOrder32Host if it's undefined) but that should not be necessary on Mac OS X 10.4 and above because the system should define it. I'd be interested to know what's the matter with the affected users' systems. The MacPorts project's bug report for this issue is here: http://trac.macports.org/ticket/16213
The check you have in the ticket isn't quite correct -- during build time, it's the SDK that matters, not the headers that are in /System. This could be a problem if someone is trying to build using the 10.3 SDK. But, the bug is really that the #ifndef kCGBitmapByteOrder block needs to be moved to cairo-quartz-private.h so that it's shared between cairo-quartz and cairo-quartz-image. I missed doing this when I split out cairo-quartz-image.
The instructions I have in my ticket are exactly correct for what I wanted to check. An SDK is not used unless the user requests to build with one. In MacPorts, we do not build with an SDK unless the +universal variant is chosen. See the new note I added to the MacPorts ticket. Apparently for some users the CGImage.h system header is missing some definitions on Mac OS X 10.4.x, and I don't know why. http://trac.macports.org/ticket/16213#comment:4
Regarding using the 10.3 SDK, you told me a couple months ago that "Pretty much all the Quartz backends require at least a recent 10.4.x. The needed methods to render using Quartz just aren't there" on Panther. http://trac.macports.org/ticket/15556#comment:3
I think we found the problem. The user in our case was using Xcode 2.0, which is so obsolete it isn't even available for download on Apple Developer Connection anymore. Probably the only people who have this version are those who bought Mac OS X 10.4.0 retail (or got 10.4.0 with their computer) and installed Xcode from there and never updated it. I've solved the problem for the MacPorts cairo port by requiring Xcode 2.4.1. If cairo wants to support using Xcode 2.0, then you should know that this is the difference between CGImage.h on a system with Xcode 2.0 and CGImage.h on a system with Xcode 2.5: http://trac.macports.org/attachment/ticket/16213/CGImage.h-dakka.akka-ryandesign.diff In other words, you should not assume, as you currently do, that just because kCGBitmapByteOrder32Host is not defined, that you are running on Mac OS X 10.3.x (or using the 10.3 SDK). Several of the things you are setting in your "#ifndef kCGBitmapByteOrder32Host" section should not be set by you on Mac OS X 10.4.x because they are already set on Mac OS X 10.4.x.
Hmm, the net result is that the MacOS X backend requires Xcode >= 2.4 (as documented). But... The implications of the bug are that we still have some obsolete 10.3 cruft in the quartz surface.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.