Detailed analysis of the problem with a patch that tells you if it a problem for you.

eselect.opengl (text/plain), 1.82 KB, created by Tres 'RiverRat' Melton on 2006-03-02 21:57:37 UTC

Ok, here's the deal.  I noticed that on my machine I have:

ls -ld lib*
drwxr-xr-x  172 root root 98304 Mar  2 22:05 lib
drwxr-xr-x    9 root root  4096 Mar  2 22:05 lib32
lrwxrwxrwx    1 root root     3 Mar  2 22:05 lib64 -> lib

and hparker has
drwxr-xr-x  172 root root 98304 Mar  2 22:05 lib64
drwxr-xr-x    9 root root  4096 Mar  2 22:05 lib32
lrwxrwxrwx    1 root root     3 Mar  2 22:05 lib -> lib64

Changing those fixed the issue so I thought I'd add a check in

/usr/share/eselect/modules/opengl.eselect

Which got intesting when I found the line that said:

for libdir in $(list_libdirs); do

After a few echo statements I discovered that the interesting
parts get executed three times with the symbolic link being 
discarded regardless of which it was.  So the loop executes 
for lib, lib32, and lib64.  The symbolic gets short circuited
and effectively discarded.  The only one that counts is the 
last run so if lib64 is the symbolic link and gets ignored
then lib32 is the last one that counts and you're screwed.
If lib is the symbolic link then the last one (and it counts)
is lib64 and there is no more disturbance in the force.

I don't know the proper solution because I can't readily see
how the script picks which of the 3 libdirs returned by 
$(list_libdirs) to use.  I did however make a patch that can
reliably tell you that you're fucked.

--- opengl.eselect.orig 2006-03-02 22:48:58.000000000 -0700
+++ opengl.eselect      2006-03-02 22:41:00.000000000 -0700
@@ -217,6 +217,7 @@
                        ldpath="${ldpath:+${ldpath}:}${PREFIX}/${libdir}/opengl/${gl_local}/lib"
 
                done
+               [[ -h ${PREFIX}/${libdir} ]] && echo -n " (RiverRat thinks the force has left you.) "
 
                store_config ${ENV_FILE} LDPATH "${ldpath}"
                store_config ${ENV_FILE} OPENGL_PROFILE "${gl_implem}"