After handling this problem: https://bugs.gentoo.org/show_bug.cgi?id=111877#c11 (see comment #11) with: rm -r /usr/lib32/opengl eselect opengl set xorg-x11 emerging xorg-server fails. Reproducible: Always Steps to Reproduce: USE="dri -ipv6 -minimal xprint" emerge --oneshot =xorg-x11-0.99.4-r2 Actual Results: if /bin/sh ../../libtool --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include -I../../include -I../../include -I../../include -I../../GL/include -I../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -I/var/tmp/portage/xorg-server-0.99.4-r2/work/Mesa-6.4.1/include -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -I../../lbx -O2 -pipe -fomit-frame-pointer -m64 -MT g_disptab.lo -MD -MP -MF ".deps/g_disptab.Tpo" \ -c -o g_disptab.lo `test -f 'g_disptab.c' || echo './'`g_disptab.c; \ then mv -f ".deps/g_disptab.Tpo" ".deps/g_disptab.Plo"; \ else rm -f ".deps/g_disptab.Tpo"; exit 1; \ fi x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include -I../../include -I../../include -I../../include -I../../GL/include -I../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -I/var/tmp/portage/xorg-server-0.99.4-r2/work/Mesa-6.4.1/include -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -I../../lbx -O2 -pipe -fomit-frame-pointer -m64 -MT g_disptab.lo -MD -MP -MF .deps/g_disptab.Tpo -c g_disptab.c -fPIC -o .libs/g_disptab.o In file included from g_disptab.c:36: glxserver.h:65:25: GL/glxproto.h: No such file or directory In file included from g_disptab.c:36: glxserver.h:107: error: parse error before "GLXContextTag" glxserver.h:107: warning: function declaration isn't a prototype glxserver.h:209: error: parse error before "xGLXMakeCurrentReply" glxserver.h:209: warning: function declaration isn't a prototype glxserver.h:211: error: parse error before "xGLXIsDirectReply" glxserver.h:211: warning: function declaration isn't a prototype glxserver.h:213: error: parse error before "xGLXQueryVersionReply" glxserver.h:213: warning: function declaration isn't a prototype glxserver.h:215: error: parse error before "xGLXQueryContextInfoEXTReply" glxserver.h:216: warning: function declaration isn't a prototype glxserver.h:218: error: parse error before "xGLXQueryExtensionsStringReply" glxserver.h:218: warning: function declaration isn't a prototype glxserver.h:220: error: parse error before "xGLXQueryServerStringReply" glxserver.h:220: warning: function declaration isn't a prototype In file included from g_disptab.c:37: glxext.h:81: error: parse error before "GLXContextTag" glxext.h:81: warning: function declaration isn't a prototype make: *** [g_disptab.lo] Error 1
I can confirm this bug with my x86 machine, so its not AMD64 specific.
(In reply to comment #1) > I can confirm this bug with my x86 machine, so its not AMD64 specific. Oh, and its specific to the +dri flag.
Created attachment 75234 [details] Mesa-6.4.1-r1 compilation output This is probably related to the bug at hand.
I found out, that what caused the problem, was emul-linux-x86-xlibs-2.2-r1, which ran "eselect opengl set --use-old", which in turn somehow managed to break the symlinks to link to emul-linux libraries in /usr/include/GL: lrwxrwxrwx 1 root root 39 Dec 23 16:16 gl.h -> /usr/lib32/opengl/xorg-x11/include/gl.h lrwxrwxrwx 1 root root 42 Dec 23 16:16 glext.h -> /usr/lib32/opengl/xorg-x11/include/glext.h lrwxrwxrwx 1 root root 40 Dec 23 16:16 glx.h -> /usr/lib32/opengl/xorg-x11/include/glx.h lrwxrwxrwx 1 root root 43 Dec 23 16:16 glxext.h -> /usr/lib32/opengl/xorg-x11/include/glxext.h lrwxrwxrwx 1 root root 42 Dec 23 16:16 glxmd.h -> /usr/lib32/opengl/xorg-x11/include/glxmd.h lrwxrwxrwx 1 root root 45 Dec 23 16:16 glxproto.h -> /usr/lib32/opengl/xorg-x11/include/glxproto.h lrwxrwxrwx 1 root root 46 Dec 23 16:16 glxtokens.h -> /usr/lib32/opengl/xorg-x11/include/glxtokens.h So one must manually relink them to the headers in /usr/lib64/opengl/xorg-x11/include/. I was unable to fix this by running "eselect opengl set xorg-x11".
xorg-server-1.0.1.ebuild: switch_opengl_implem() { # Switch to the xorg implementation. # Use new opengl-update that will not reset user selected # OpenGL interface ... echo eselect opengl set --use-old ${OPENGL_DIR} } This DID RESET the symlinks thou, so again i had to RESET them myself during compilation.
*** Bug 116501 has been marked as a duplicate of this bug. ***
I can confirm the same problem. I'm manually relinking, and if I continue to have problems, I'll post them here. Here's what I did (in case anyone else wants to avoid retyping): eselect opengl set xorg-x11 cd /usr/include/GL rm gl.h ln -s /usr/lib64/opengl/xorg-x11/include/gl.h gl.h rm glext.h ln -s /usr/lib64/opengl/global/include/glext.h glext.h rm glx.h ln -s /usr/lib64/opengl/xorg-x11/include/glx.h glx.h rm glxext.h ln -s /usr/lib64/opengl/global/include/glxext.h glxext.h rm glxmd.h ln -s /usr/lib64/opengl/xorg-x11/include/glxmd.h glxmd.h rm glxproto.h ln -s /usr/lib64/opengl/xorg-x11/include/glxproto.h glxproto.h rm glxtokens.h ln -s /usr/lib64/opengl/xorg-x11/include/glxtokens.h glxtokens.h This is with xorg-server-1.0.1 (might want to update the summary) UPDATE: This seems to have worked, xorg-server compiled :) W
> Here's what I did (in case anyone else wants to avoid retyping): I just figured out, that one can save a lot of typing by using ln -sf /usr/lib64/opengl/xorg-x11/* /usr/include/GL/ I noticed that you linked some files from /usr/lib64/opengl/global. I'm just wondering, but didn't glxext.h and glext.h exist in /usr/lib64/opengl/xorg-x11/?
I've been looking for /usr/lib32/opengl in etc (and some other places) to see why such symlinks are created in the first place. What I thought is if it was problem with eselect? Having edited /etc/env.d/03opengl which originally was: # Configuration file for eselect # This file has been automatically generated. LDPATH="/usr/lib32/opengl/xorg-x11/lib" OPENGL_PROFILE="xorg-x11" changing: LDPATH to "/usr/lib64/opengl/xorg-x11/lib" and running eselect set opengl xorg-x11 causes original file to restore. lib32 can be found in /usr/share/eselect/modules/opengl.eselect and it is said handle "specially" emul libs. Aren't just emul - libs too old? Also, what is this path used for anyway (env-update does not re-create symlinks...) ?
Yes, this is a known problem with eselect. *** This bug has been marked as a duplicate of 109922 *** *** This bug has been marked as a duplicate of 109922 ***
I suppose not only with eselect but with app-emulation/emul-linux-x86-xlibs as well ;)
