cairo 1.10.0 documents that it requires Xlib if you're going to build the xlib backend, which is obviously pretty important on UNIX and Linux. The README doesn't document which *version* of xlib it requires, though. At least with cairo 1.8.x, it was possible to build against the Xlib that comes with Solaris 10, which I believe is 6.8.x. With 1.10.0, the build now fails in cairo-xlib-surface.c. The Solaris Xlib is apparently missing XLinearGradient: libtool: compile: cc -xO4 -xipo=2 -DHAVE_CONFIG_H -I. -I.. -I. -D_REENTRANT -I/local/include/pixman-1 -I/local/include -I/local/include/freetype2 -I/local/include -I/local/include/libpng14 -DXTHREADS -I/local/include -I/usr/openwin/include -I/usr/openwin/include -erroff=E_ENUM_TYPE_MISMATCH_ARG -erroff=E_ENUM_TYPE_MISMATCH_OP -Wp,-D_FORTIFY_SOURCE=2 -I/local/include -I/local/gnu/include -I/usr/local/include -Xa -xO4 -xipo=2 -xstrconst -KPIC -mt -xtarget=native -m64 -xarch=native -I/local/include -I/local/gnu/include -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -c cairo-xlib-surface.c -KPIC -DPIC -o .libs/cairo-xlib-surface.o "cairo-xlib-surface.c", line 2133: undefined symbol: XLinearGradient "cairo-xlib-surface.c", line 2133: syntax error before or at: grad "cairo-xlib-surface.c", line 2161: undefined symbol: grad I'll be happy to provide more information if needed. I'm just wondering if the requirement for Xlib was intentionally increased, or if this was more of an accident?
It is defined in cairo-xlib-xrender-private.h if Render < 0.10. On my Solaris 10, Render is 0.10, but it doesn't have XLinearGradient.
(In reply to comment #1) > It is defined in cairo-xlib-xrender-private.h if Render < 0.10. > On my Solaris 10, Render is 0.10, but it doesn't have XLinearGradient. Maybe its availability could be detected at configure-time, but I believe it should be available in Render 0.10. You probably have a pre-0.10 X11/extensions/Xrender.h header and a 0.10 (or better) X11/extensions/render.h
(In reply to comment #1) > It is defined in cairo-xlib-xrender-private.h if Render < 0.10. > On my Solaris 10, Render is 0.10, but it doesn't have XLinearGradient. It looks like a known bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=7002125 Can you confirm if it has been fixed by the update mentioned in this bugreport?
I'm afraid I can't test whether that OpenSolaris update fixes the issue, as I'm not running OpenSolaris, I'm running Solaris 10u6 with all patches applied, before Oracle pulled access to patches. I'm also not using the render/Xrender from the operating system, I'm using renderproto-0.9.2 and libXrender-0.9.0 compiled from source. These were the same versions of the two packages that I used with cairo 1.8.x.
(In reply to comment #4) > I'm afraid I can't test whether that OpenSolaris update fixes the issue, as I'm > not running OpenSolaris, I'm running Solaris 10u6 with all patches applied, > before Oracle pulled access to patches. > > I'm also not using the render/Xrender from the operating system, I'm using > renderproto-0.9.2 and libXrender-0.9.0 compiled from source. These were the > same versions of the two packages that I used with cairo 1.8.x. If you are using these packages, the test #if RENDER_MAJOR == 0 && RENDER_MINOR < 10 should be true in cairo-xlib-xrender-private.h, so XLinearGradient should be defined. Can you check those macros and/or the output of the C preprocessor?
You've illuminated the problem. My render.h (from renderproto-0.9.2) has #define RENDER_NAME "RENDER" #define RENDER_MAJOR 0 #define RENDER_MINOR 10 So the test in cairo-xlib-xrender-private.h is not true, and that header is not defining the necessary structs. It appears that the render.h from renderproto-0.9.2 "jumped the gun" and defined RENDER_MINOR 10, instead of RENDER_MINOR 9 like it probably should have. Now that I know where the issue is, I suppose I could patch my copy of renderproto-0.9.2 to set RENDER_MINOR 9, but that only helps me. Is it worth trying to develop a more general solution for others that might run into this issue?
(In reply to comment #6) > You've illuminated the problem. My render.h (from renderproto-0.9.2) has > > #define RENDER_NAME "RENDER" > #define RENDER_MAJOR 0 > #define RENDER_MINOR 10 > > So the test in cairo-xlib-xrender-private.h is not true, and that header is not > defining the necessary structs. > > It appears that the render.h from renderproto-0.9.2 "jumped the gun" and > defined RENDER_MINOR 10, instead of RENDER_MINOR 9 like it probably should > have. Yes, this seems to be the problem. > > Now that I know where the issue is, I suppose I could patch my copy of > renderproto-0.9.2 to set RENDER_MINOR 9, but that only helps me. Is it worth > trying to develop a more general solution for others that might run into this > issue? If the package is incorrect, you might try reporting it as a bug to the its maintainers. I don't know Solaris package system, but I guess that if you could provide a patch which fixes the problem, the maintainers would be happy to test and merge it (unless it's already available in updated versions).
This isn't a Solaris package that's in error, it's the stock renderproto-0.9.2 source. I installed it and libXrender from source on my workstation. I've stuck with renderproto-0.9.2 and libXrender-0.9.0 because up until now cairo and other packages have worked great with them, and later versions essentially require a huge number of dependencies from Xorg, such that I would be required to build most or all of the Xorg distribution.
(In reply to comment #4) > I'm afraid I can't test whether that OpenSolaris update fixes the issue, as I'm > not running OpenSolaris, I'm running Solaris 10u6 with all patches applied, > before Oracle pulled access to patches. While the bug report is shown on opensolaris.org, that bug is a Solaris 10 bug, with the fix delivered in Solaris 10 patch 119060-57, though as noted, you'ld need a support contract to get a patch that new (it's only a couple weeks old). (In reply to comment #0) > At least with cairo 1.8.x, it was possible to build against the Xlib that comes > with Solaris 10, which I believe is 6.8.x. It's based on X11R6.6 actually, since it doesn't include XFree86 additions like the Xutf8* functions that were folded into X11R6.7.
Created attachment 43047 [details] [review] Fix for autoconf Could you please test if the attachment fixes the problem for you?
Thanks Andrea, your proposed autoconf checks do get me by the issue I was having with XLinearGradient. Everything appears to build now.
(In reply to comment #11) > Thanks Andrea, your proposed autoconf checks do get me by the issue I was > having with XLinearGradient. Everything appears to build now. Fixed in master (d866bb0405bc989666f886e2c0e293a1fe718d74) and 1.10 (9d37bd963005549640171c88aa519eba3e1d0e34).
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.