| Summary: | x11-libs/cairo-1.10.0-r3 with USE="aqua -X" fails due to X11-calls, installs broken .pc files. | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Heiko <lil_tux> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | major | CC: | lucamarturana |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | OS X | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Compilation error due to glx.
Fix compilation for macos. gl.pc drawft |
||
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 |
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.