Bugzilla Bug 129030

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 ***