libtool: link: x86_64-pc-linux-gnu-gcc -m32 -pthread -I/usr/include/gio-unix-2.0/ -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -pipe -march=core2 -O2 -Wl,-O1 -Wl,--as-needed -o .libs/rsvg-convert rsvg_convert-rsvg-convert.o rsvg_convert-rsvg-size-callback.o ./.libs/librsvg-2.so -lpng16 -lcroco-0.6 -lxml2 -lgio-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo -lm -pthread /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libEGL.so.1, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so, not found (try using -rpath or -rpath-link) /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglMakeCurrent' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglDestroySurface' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglChooseConfig' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglQueryContext' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglCreatePbufferSurface' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglQueryString' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglGetCurrentContext' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglSwapBuffers' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib32/libcairo.so: undefined reference to `eglGetCurrentSurface' collect2: error: ld returned 1 exit status Makefile:855: recipe for target 'rsvg-convert' failed make[2]: *** [rsvg-convert] Error 1 make[2]: Leaving directory '/var/tmp/portage/gnome-base/librsvg-2.40.8/work/librsvg-2.40.8-abi_x86_32.x86' Makefile:1307: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/gnome-base/librsvg-2.40.8/work/librsvg-2.40.8-abi_x86_32.x86' Makefile:705: recipe for target 'all' failed make: *** [all] Error 2
Created attachment 400236 [details] emerge --info
Created attachment 400238 [details] emerge -pqv
Created attachment 400240 [details] build.log
One more bit of info...switching from ATI to xorg-x11 causes the ebuild to work: # eselect opengl list Available OpenGL implementations: [1] ati * [2] xorg-x11 # eselect opengl set 2 Switching to xorg-x11 OpenGL interface... done # source /etc/profile # emerge -1av gnome-base/librsvg I then switched it back, expecting it to fail: # eselect opengl set 1 Switching to ati OpenGL interface... done # source /etc/profile # emerge -1av gnome-base/librsvg ...but this time, it worked. Weird. As this was in the middle of an emerge -auND world, it was a bit annoying, but at least the rebuild is back on track now.
(In reply to Scott Alfter from comment #4) > One more bit of info...switching from ATI to xorg-x11 causes the ebuild to > work: > > # eselect opengl list > Available OpenGL implementations: > [1] ati * > [2] xorg-x11 > # eselect opengl set 2 > Switching to xorg-x11 OpenGL interface... done > # source /etc/profile > # emerge -1av gnome-base/librsvg > > I then switched it back, expecting it to fail: > > # eselect opengl set 1 > Switching to ati OpenGL interface... done > # source /etc/profile > # emerge -1av gnome-base/librsvg > > ...but this time, it worked. Weird. As this was in the middle of an emerge > -auND world, it was a bit annoying, but at least the rebuild is back on > track now. @x11 team, any suggestions about what's going on here? Was there a multilib bug in a previous eselect-opengl release? If so, maybe it makes sense to run eselect opengl in cairo's or mesa's pkg_postinst?
(In reply to Alexandre Rostovtsev from comment #5) > (In reply to Scott Alfter from comment #4) > > One more bit of info...switching from ATI to xorg-x11 causes the ebuild to > > work: > > > > # eselect opengl list > > Available OpenGL implementations: > > [1] ati * > > [2] xorg-x11 > > # eselect opengl set 2 > > Switching to xorg-x11 OpenGL interface... done > > # source /etc/profile > > # emerge -1av gnome-base/librsvg > > > > I then switched it back, expecting it to fail: > > > > # eselect opengl set 1 > > Switching to ati OpenGL interface... done > > # source /etc/profile > > # emerge -1av gnome-base/librsvg > > > > ...but this time, it worked. Weird. As this was in the middle of an emerge > > -auND world, it was a bit annoying, but at least the rebuild is back on > > track now. > > @x11 team, any suggestions about what's going on here? Was there a multilib > bug in a previous eselect-opengl release? > > If so, maybe it makes sense to run eselect opengl in cairo's or mesa's > pkg_postinst? Probably related to ati-drivers not providing a libEGL, but I'm not entirely sure how since eselect-opengl doesn't handle libEGL. Switching to xorg-x11 doesn't seem tractable given the number of things that link with cairo. cairo's dependency on libEGL stems from our unwarranted USE=opengl behavior, which enables an experimental developer-only GL backend for cairo (which applications using cairo can't even make use of without changes!) I think this is further evidence that we should remove the opengl USE flag. I need to sort out bug 549912 first and then I can take a look at that.
Crap. Can't remove cairo's opengl USE flag -- webkit-gtk actually does rely on it.
(In reply to Matt Turner from comment #7) > Crap. Can't remove cairo's opengl USE flag -- webkit-gtk actually does rely > on it. Yes, webkit really requires cairo-egl and cairo-gl for webgl on X. And probably will start requiring cairo-gles2 for webgl on wayland at some point. I don't understand is the bizarre automagic relationships between egl, gles2, gl, and glx in cairo's build system. Why can't they be separated out in some sane manner?
is this still valid with updated tree? :/
(In reply to Pacho Ramos from comment #9) > is this still valid with updated tree? :/ Hard to care, since ati-drivers is being tree cleaned. I just updated the title so I would be able to find it when it comes time to mark all ati-drivers bugs as WONTFIX :)
ati-drivers is dead, and will not be supported for X.
