When emerging x11-libs/cairo-1.10.0-r3 with USE="aqua -X" it fails when linking libcairo. The reason seems to be the (automatic) detection and usage of GLX components ("GLX functions: yes"). Reproducible: Always Steps to Reproduce: 1. env USE="aqua -X" emerge -1 cairo 2. 3. Actual Results: CCLD libcairo.la Undefined symbols: "_XFree", referenced from: _cairo_glx_device_create in cairo-glx-context.o _cairo_glx_device_create in cairo-glx-context.o "_XCreateColormap", referenced from: _cairo_glx_device_create in cairo-glx-context.o "_XCreateWindow", referenced from: _cairo_glx_device_create in cairo-glx-context.o "_XDestroyWindow", referenced from: __glx_destroy in cairo-glx-context.o _cairo_glx_device_create in cairo-glx-context.o "_XFreeColormap", referenced from: _cairo_glx_device_create in cairo-glx-context.o "_XFlush", referenced from: _cairo_glx_device_create in cairo-glx-context.o ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [libcairo.la] Error 1 make[3]: Leaving directory `/Gentoo/var/tmp/portage/x11-libs/cairo-1.10.0-r3/work/cairo-1.10.0/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/Gentoo/var/tmp/portage/x11-libs/cairo-1.10.0-r3/work/cairo-1.10.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Gentoo/var/tmp/portage/x11-libs/cairo-1.10.0-r3/work/cairo-1.10.0' make: *** [all] Error 2 emake failed * ERROR: x11-libs/cairo-1.10.0-r3 failed: * emake failed Adding --disable-glx fixes compilation of cairo. Additional problem is the installation of broken .pc files: pkg-config --cflags cairo / pkg-config --cflags cairo Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing `gl.pc' to the PKG_CONFIG_PATH environment variable Package 'gl', required by 'cairo', not found This breaks x11-libs/gtk+-2.20.1-r1 compilation (and probably renders every other depending package broken): checking for cairo-pdf.h... no configure: error: *** Can't find cairo-pdf.h. You must build Cairo with the pdf *** backend enabled. I'm not quite sure if cairo is at fault (because it compiles/installs without complaint and even enables OpenGL) or we (because we don't provide a gl.pc). Anyway, gl.pc is usually provided by Mesa aka xorg-x11 opengl, which I don't want to spam my x64-macos with.
Created attachment 247877 [details] Compilation error due to glx.
Created attachment 247879 [details, diff] Fix compilation for macos.
(In reply to comment #2) > Created an attachment (id=247879) [details] > Fix compilation for macos. > That patch only fixes compilation. The broken .pc file issue still persists. Testing a manual compilation yields the same results. I was able to manually compile gtk+ after removing the dependency gl.pc from cairo's .pc files, though that's a bit harsh. Maybe opengl-apple should provide gl.pc instead, just like Mesa does?
Ok, looks like cairo's fault, when looking at configure.ac: CAIRO_ENABLE_SURFACE_BACKEND(gl, OpenGL, no, [ gl_REQUIRES="gl" PKG_CHECK_MODULES(gl, $gl_REQUIRES,, [ dnl Fallback to searching for headers AC_CHECK_HEADER(GL/gl.h,, [use_gl="no (gl.pc nor OpenGL headers not found)"]) if test "x$use_gl" = "xyes"; then gl_NONPKGCONFIG_CFLAGS= gl_NONPKGCONFIG_LIBS="-lGL" fi]) So it relies on gl.pc for OpenGL after installation, but doesn't enforce it's presence on configuration time since it falls back to header detection. That still leaves us to provide a proper gl.pc for OpenGL, though.
I'm all for providing one in the first place.
Created attachment 248009 [details, diff] gl.pc drawft
(In reply to comment #5) > I'm all for providing one in the first place. > Yeah me too. Though, I'm not quite sure if we should use the OpenGL framework instead of (x11) libGL in media-libs/opengl-apple and/or the gl.pc?
(In reply to comment #6) > Created an attachment (id=248009) [details] > gl.pc drawft > Just built gtk+ with it. Seems to roll so far...
(In reply to comment #7) > Yeah me too. Though, I'm not quite sure if we should use the OpenGL framework > instead of (x11) libGL in media-libs/opengl-apple and/or the gl.pc? We dropped the framework thing last time, simply because apps doing the unix linking way should not get aqua stuff. Using -framework OpenGL should do the right linking for that. Not sure what cairo is going to do with it.
gl.pc file added to apple-opengl-4
(In reply to comment #10) > gl.pc file added to apple-opengl-4 > Ok the [cairo-]gl.pc issue seems to be fixed and x11-libs/gtk+ is successfully emergable. Though the problem of compiling x11-libs/cairo itself still persists. I'd like to see something like $(use_disable aqua glx) for USE=aqua to fix the compilation of cairo by not using X11-only glx (Yes, I know that there's unfortunately no use_disable).
there is $(use_enable !aqua glx) :)
(In reply to comment #12) > there is $(use_enable !aqua glx) :) > Yeah, but OpenGL shouldn't be enable for !aqua per default, should it?
I think I don't get it then use_enable a X results in --enable-X or --disable-X based on use a inverting a just makes it do use_disable, doesn't it?
(In reply to comment #14) > I think I don't get it then > > use_enable a X results in --enable-X or --disable-X based on use a > inverting a just makes it do use_disable, doesn't it? > No, it doesn't. Though `use_enable !aqua glx` works for USE=aqua that it correctly adds --disable-glx, BUT for any USE=-aqua it explicitly enables --enable-glx, even if USE=-opengl -- dunno if that would make configure barf. I thought of `use_disable aqua glx` just disabling glx if USE=aqua otherwise doing nothing. Probably we should use something like 'use aqua && myconf+=" --disable-glx"'?
oh, like that, yeah
as far as I can see, 1.12.16 works better
