the offending package name is eselect-opengl the fix is at least superficially trivial but may be harder to get working on all systems. the most serious effect of the problem is that it causes the build of xorg-server (the 'modular' version) to fail which is pretty bad for people who were using a pre 6.9 version and have had to unmerge xorg completely before building the new one. versions: i am working off the portage tree from yesterday or the day before, and I have ACCEPT_KEYWORDS=tilde amd64 (sorry I cant type a tilde on this stupid windows box) I set the platform to amd64 but I guess this bug is likely to affect any platform which has /usr/lib /usr/lib32 /usr/lib64 etc. full description: Running eselect opengl set xorg-x11 ends up using the /usr/lib32/opengl directory instead of the /usr/lib64/opengl directory. The result is that the /usr/include/GL/glxproto.h link it sets up points to a glxproto.h does not include various definitions required for building xorg, and a build of xorg-x11 v7.0 fails. there is a section within eselect-opengl (search for amd64 within the file) which looks intended to actually stop this from happenning, however at least on my system it had the opposite effect. why it happens (on my system): (I am going from memory here because my main comp is still unusable at the moment) the opengl eselect module processes each lib directory produced by 'list_libdirs' in my system this is 'lib', 'lib32'and 'lib64' each dir is processed in turn, and if it contains the opengl dir it the symlinks in /usr/include/GL etc are changed to point to there. my system has this: /usr/lib -> /usr/lib64 and the /usr/lib64/opengl is where the correct headers are installed lib64 is last in the list and so should be processed last but instead it is ignored by what looks like an old check that checks if it is a symlink and ignores it. because the lib64 was ignored, the last symlinks set up were the ones directed to the lib32 dir, and thus incorrect. I fixed it by changing the check so that it does not skip that lib64 dir. (perhaps the check is from way back when the default lib32/lib64 dirs were switched around? i have some vague memories of that ). Having said that, I do not know if that will break it for people using the emul-x86 opengl libs and I can't really test that at the moment. so people with the problem can find this page, the xorg build fails with errors about unknown symbols related to glx hyperpipe network requests/responses. one of which is: xGLXQueryHyperpipeNetworkSGIXReq the header which these symbols are defined in is glxproto.h I did find a single page where someone else (from march 30 2006) had this build error which you can look at to see more of the output from xorg. http://forums.gentoo.org/viewtopic-t-377400-postdays-0-postorder-asc-start-875.html
*** This bug has been marked as a duplicate of 109922 ***
