[cairo] Build failures with cached configure results
psychon at znc.in
Tue Mar 15 12:07:13 PDT 2011
the current configure.ac often causes build failures when configure is re-run
with a cache. For example, I just had this build failure:
In file included from cairo-xlib-private.h:42,
cairo-xlib-xrender-private.h:102: error: redefinition of ‘struct _XLinearGradient’
cairo-xlib-xrender-private.h:105: error: conflicting types for ‘XLinearGradient’
/usr/include/X11/extensions/Xrender.h:189: note: previous declaration of
‘XLinearGradient’ was here
(This can be triggered with 'touch configure.ac && make')
The reason for this is that all the different CAIRO_ENABLE_* macros are used
incorrectly. These macros map to _CAIRO_ENABLE in build/aclocal.enable.m4 which
runs the specified test command via AC_CACHE_CHECK. AC_CACHE_CHECK's
documentation contains this:
The commands-to-set-it must have no side effects except for setting
the variable cache-id, see below.
The reason for the build "redefinition of struct _XLinearGradient" that I
mentioned above is that the CAIRO_ENABLE_SURFACE_BACKEND for xlib_xrender uses
AC_CHECK_FUNCS in it's "COMMANDS" for checking. So if the result for
xlib_xrender is taken from the cache, the AC_CHECK_FUNCS for
XRenderCreate*Gradient is not executed.
The problem here is that basically no code in configure.ac gets this right and
thus it would be a huge task to fix this.
Attached is a patch which disables the cache for _CAIRO_ENABLE. This is a bad
idea to do, but works for me(tm).
Any suggestions what can be done about this? Who's the local autoconf expert who
feels obligated to fix this? ;-)
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 629 bytes
Desc: not available
More information about the cairo