An abbreviated output is below. The full output plus emerge --info is attached. I have tried re-emerging eselect eselect-config nvidia-glx protogl mesa xorg-server and making the xorg glx headers symlinks to those in /usr/.../OpenGL. None of this worked. if /bin/sh ../../libtool --tag=CC --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-1.0.2-r7/work/Mesa-6.4.2/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 -MT glxcmdsswap.lo -MD -MP -MF ".deps/glxcmdsswap.Tpo" -c -o glxcmdsswap.lo glxcmdsswap.c; \ then mv -f ".deps/glxcmdsswap.Tpo" ".deps/glxcmdsswap.Plo"; else rm -f ".deps/glxcmdsswap.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-1.0.2-r7/work/Mesa-6.4.2/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 -MT glxcmds.lo -MD -MP -MF .deps/glxcmds.Tpo -c glxcmds.c -fPIC -DPIC -o .libs/glxcmds.o glxcmds.c: In function `__glXBindSwapBarrierSGIX': glxcmds.c:1749: warning: cast to pointer from integer of different size glxcmds.c: In function `__glxQueryHyperpipeNetworkSGIX': glxcmds.c:1796: error: `xGLXQueryHyperpipeNetworkSGIXReq' undeclared (first use in this function) glxcmds.c:1796: error: (Each undeclared identifier is reported only once glxcmds.c:1796: error: for each function it appears in.) glxcmds.c:1796: error: `req' undeclared (first use in this function) glxcmds.c:1796: error: syntax error before ')' token glxcmds.c:1797: error: `xGLXQueryHyperpipeNetworkSGIXReply' undeclared (first use in this function) glxcmds.c:1812: error: `reply' undeclared (first use in this function) glxcmds.c:1825: error: `sz_xGLXQueryHyperpipeNetworkSGIXReply' undeclared (first use in this function) glxcmds.c: In function `__glxDestroyHyperpipeConfigSGIX': glxcmds.c:1836: error: `xGLXDestroyHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1836: error: `req' undeclared (first use in this function) glxcmds.c:1837: error: syntax error before ')' token glxcmds.c:1838: error: `xGLXDestroyHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1851: error: `reply' undeclared (first use in this function) glxcmds.c:1863: error: `sz_xGLXDestroyHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c: In function `__glxQueryHyperpipeConfigSGIX': glxcmds.c:1871: error: `xGLXQueryHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1871: error: `req' undeclared (first use in this function) glxcmds.c:1872: error: syntax error before ')' token glxcmds.c:1873: error: `xGLXQueryHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1889: error: `reply' undeclared (first use in this function) glxcmds.c:1904: error: `sz_xGLXQueryHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c: In function `__glxHyperpipeConfigSGIX': glxcmds.c:1915: error: `xGLXHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1915: error: `req' undeclared (first use in this function) glxcmds.c:1916: error: syntax error before ')' token glxcmds.c:1917: error: `xGLXHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1935: error: `reply' undeclared (first use in this function) glxcmds.c:1949: error: `sz_xGLXHyperpipeConfigSGIXReply' undeclared (first use in this function) make[2]: *** [glxcmds.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... 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-1.0.2-r7/work/Mesa-6.4.2/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 -MT glxcmdsswap.lo -MD -MP -MF .deps/glxcmdsswap.Tpo -c glxcmdsswap.c -fPIC -DPIC -o .libs/glxcmdsswap.o make[2]: Leaving directory `/var/tmp/portage/xorg-server-1.0.2-r7/work/xorg-server-1.0.2/GL/glx' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/xorg-server-1.0.2-r7/work/xorg-server-1.0.2/GL' make: *** [all-recursive] Error 1 !!! ERROR: x11-base/xorg-server-1.0.2-r7 failed.
reopen with emerge info
Created attachment 90640 [details] Full compile output plus emerge --info Part of the middle was removed because it was a little too large.
reporter: please reopen that bug i've got the same bug i tried to unmerge nvidia-glx and it didn't help any ideas? (amd64 too)
I have this exactly same problem on amd64 platform as well. I couldn't find any workarounds either by removing or re-emerging packages.
No resolution. emerge --info in attachment.
ok, unmerging emul-linux-x86-xlibs (2.2.2!) helped see bugs: 111877, 109922
The problem is that '/usr/include/GL/glxproto.h' is symlinked to '//usr/lib32/opengl/xorg-x11/include/glxproto.h'. This should be '/usr/lib/opengl/xorg-x11/include/glxproto.h' of course. The symlink is created by 'eselect opengl set xorg-x11 --impl-headers', which is called from the ebuild, so manually correcting the symlink does not work. The responsible code is in '/usr/share/eselect/modules/opengl.eselect'. As a temporary fix you can change line 120 in that file from "[[ -d ${PREFIX}/${libdir}/opengl ]] || continue" into "continue". Hopefully some gentoo-dev can provide a proper fix with this info.
I had this same problem on an AMD64 with NVIDIA drivers. I was able to solve it when I found bug #109922 (in particular comments 18 and 19). To solve it you don't have to edit eselect code. I got xorg-server to compile by emerging: emul-linux-x86-xlibs-7.0-r1 emul-linux-x86-baselibs-2.5 Which are both still marked as unstable (emul-linux-x86-baselibs-2.5 is a dependency of emul-linux-x86-xlibs-7.0-r1).
Unless you depend on the fixed version or block the broken version, people will continue to hit this.
AMD64 team, suggested solution? At least get emul-xlibs stable, not sure what else should be done.
no way to stablize emul-xlibs-7.0 before bug 136944 is fixed.
*** Bug 138850 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > *** Bug 138850 has been marked as a duplicate of this bug. *** > hi jakub: do you know everything? :-). thanks. I would also strongly suggest adding blockers to packages (specifically, here, emul-linux-x86-xlibs-2.2.2) known to block the emergence of xorg-x11 under amd64. regards, /iaw
(In reply to comment #9) > Unless you depend on the fixed version or block the broken version, people will > continue to hit this. Indeed, I just got hit by this, more than a week after xorg-x11 for amd64 'stabilized'. This is a problem that was known since the beginning of april (see bug 109922). For me, this is the second stable xorg-x11 emerge that causes trouble on amd64 recently because of library location troubles. I advise keeping xorg-x11 ebuilds in unstable somewhat longer than their x86 counterparts and I would greatly appreciate -- as Jacob suggested -- that blocks are put in place as fast as a problem is diagnosed. Adding a note to the upgrade guide could also help. Sorry for the complaint, I do appreciate the effort of the developers, but I think keeping things unstable until all known problems are addressed is something gentoo users should be able to expect. Finding workarounds in bugreports, as I'm doing now, is something for unstable packages.
minor xorg 7 question (not related). is /usr/X11R6 going to become /usr/X11R7 ? /iaw
(In reply to comment #15) > minor xorg 7 question (not related). is /usr/X11R6 going to become /usr/X11R7 No, it's becoming /usr.
*** Bug 140959 has been marked as a duplicate of this bug. ***
emul-xlibs is stable, assume it's fixed
actually, it isn't
Always nice to be hit by a bug in a "stable" package. Especially nice if the package is the X server, since you are basically forced to update it with any "emerge --update xxxxx" command. Is gentoo now also shipping (i.e. making stable) with known major bugs? Ob-Solution: If your /usr/lib64 is a symlink to /usr/lib (which seems to be one of the reasons of this bug), you have to change it around (see bug 109922 comments 11 and 14). So do rm /usr/lib64 mv /usr/lib /usr/lib64 ln -s /usr/lib64 /usr/lib
(In reply to comment #19) > actually, it isn't > What's wrong now?
(In reply to comment #18) > emul-xlibs is stable, assume it's fixed (In reply to comment #19) > actually, it isn't i hope that makes it clear :)
Oooh, you meant it's not stable, not that it *is* stable but doesn't fix the problem. I get it :)
*** Bug 142081 has been marked as a duplicate of this bug. ***
emul-xlibs really is now stable, fixed.
