Bugzilla Bug 109922

I ran into issues merging xorg-server-0.99.2 and discovered that the updated
glxproto.h that was required existed in /usr/lib64/opengl/xorg-x11/include, but
the /usr/include/GL/glxproto.h was pointing at
/usr/lib32/opengl/xorg-x11/include/glxproto.h.

After hacking-up eselect-opengl to not change the include symlinks when
${libdir} is lib32, everything was linked as expected.

Since x11-proto/glproto installs glx headers into lib64 on amd64, eselect should
link these files from there and not from the emul opengl headers.

Indeed. Temporarily unmerging emul-linux-x86-xlibs before emerge xorg-server
helps also ;)

Created an attachment (id=73418) [details]
Fixes multilib issue

Not sure if this is the correct fix, but it works for me

*** Bug 114450 has been marked as a duplicate of this bug. ***

This is at least partially complicated by the fact that eselects list_libdirs()
no longer lists 'lib' for amd64, see bug #114274.

Is this going to be fixed? I have to keep switching /etc/env.d/03opengl between
32 and 64bit to get mplayer and mplayer-bin to work

*** Bug 115029 has been marked as a duplicate of this bug. ***

This should be fixed with eselect-1.0, please test.

Doesn't appear to be fixed here.  The symlinks in /usr/include/GL are pointing
at /usr/lib32/opengl/, which is a symlink to /emul/linux/x86/usr/lib/opengl...

araqiel ~ # eselect opengl set xorg-x11
Switching to xorg-x11 OpenGL interface... done
araqiel ~ # ls -l /usr/include/GL/gl*.h
-rw-r--r-- 1 root root  10381 2005-12-29 05:16 /usr/include/GL/gle.h
-rw-r--r-- 1 root root 469821 2005-12-28 15:48 /usr/include/GL/glew.h
lrwxrwxrwx 1 root root     40 2006-02-10 14:15 /usr/include/GL/glext.h ->
/usr/lib32/opengl/global/include/glext.h
-rw-r--r-- 1 root root   4308 2006-02-09 05:35 /usr/include/GL/glfbdev.h
lrwxrwxrwx 1 root root     39 2006-02-10 14:15 /usr/include/GL/gl.h ->
/usr/lib32/opengl/xorg-x11/include/gl.h
-rw-r--r-- 1 root root  77761 2006-02-09 05:35 /usr/include/GL/gl_mangle.h
-rw-r--r-- 1 root root  16668 2006-02-09 05:35 /usr/include/GL/glu.h
-rw-r--r-- 1 root root   3315 2006-02-09 05:35 /usr/include/GL/glu_mangle.h
-rw-r--r-- 1 root root   4109 2006-02-09 16:20 /usr/include/GL/glutf90.h
-rw-r--r-- 1 root root  30192 2006-02-09 16:20 /usr/include/GL/glut.h
-rw-r--r-- 1 root root  41495 2005-12-28 15:48 /usr/include/GL/glxew.h
lrwxrwxrwx 1 root root     41 2006-02-10 14:15 /usr/include/GL/glxext.h ->
/usr/lib32/opengl/global/include/glxext.h
lrwxrwxrwx 1 root root     40 2006-02-10 14:15 /usr/include/GL/glx.h ->
/usr/lib32/opengl/xorg-x11/include/glx.h
-rw-r--r-- 1 root root   4257 2006-02-09 05:28 /usr/include/GL/glxint.h
-rw-r--r-- 1 root root   2031 2006-02-09 05:35 /usr/include/GL/glx_mangle.h
lrwxrwxrwx 1 root root     42 2006-02-10 14:15 /usr/include/GL/glxmd.h ->
/usr/lib32/opengl/xorg-x11/include/glxmd.h
lrwxrwxrwx 1 root root     45 2006-02-10 14:15 /usr/include/GL/glxproto.h ->
/usr/lib32/opengl/xorg-x11/include/glxproto.h
lrwxrwxrwx 1 root root     46 2006-02-10 14:15 /usr/include/GL/glxtokens.h ->
/usr/lib32/opengl/xorg-x11/include/glxtokens.h
araqiel ~ # ls -l /usr/lib32/opengl
total 12
drwxr-xr-x 3 root root 4096 2005-11-28 00:18 ati
drwxr-xr-x 3 root root 4096 2005-02-15 02:41 global
drwxr-xr-x 6 root root 4096 2006-02-09 16:40 nvidia
lrwxrwxrwx 1 root root   39 2005-12-28 17:40 xorg-x11 ->
/emul/linux/x86/usr/lib/opengl/xorg-x11
araqiel ~ # emerge -pv eselect eselect-opengl

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] app-admin/eselect-1.0  USE="bash-completion -doc" 0 kB
[ebuild   R   ] app-admin/eselect-opengl-1.0.3  0 kB

Total size of downloads: 0 kB

I have the same symlinks as previous comment (#8).
However eselect-1.0 seems to have fixed all my previous issues.

Now I can run both x86 and amd64 3D applications. And I'm also able to compile
'x11-misc/3ddesktop-0.2.9'.

Created an attachment (id=79409) [details]
change lib32 -> lib

Currently using eselect-1.0_rc2, but this bug has been bothering me for awhile.
Several files in /usr/include/GL/*.h are pointing to the (outdated)
/usr/lib32/[stuff] versions, which breaks xorg compilation (among other
things).

This patch fixes things for me, by changing "lib32" to just "lib".

I also still observe the header symlink issue. I think this might be due to the
fact that my system was installed with the 2004.3 profile and later upgraded to
2005.0 and 2005.1, so /usr/lib64 is a symlink to /usr/lib, not the other way
around.

Isn't this something that needs to be changed in eselect-opengl in the location
pointed out by Roy Marples' patch? I've successfully used a modified version of
it for a while.

On the other hand, if it is incorrect to have lib64 as a symlink, then maybe
eselect or its ebuild could check for this and refuse to continue with a clear
error message?

*** Bug 124703 has been marked as a duplicate of this bug. ***

Created an attachment (id=81175) [details]
Detailed analysis of the problem with a patch that tells you if it a problem
for you.

Created an attachment (id=81190) [details]
opengl.eselect includefix

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

The chunk of code the sets up the includes is actually executed once for each
libdir and the latter run overwrites the first. Therefore whichever libdir is
passed last is the one that's used. If you have lib64 as a symlink then only
lib, lib32 are passed in that order and so the includes end up pointing to
lib32.

This patch may look scary but all I've actually done is move the chuck of code
that sets up the includes outside of the for loop so that it only gets executed
once, for the default libdir. Please test.

*** Bug 123834 has been marked as a duplicate of this bug. ***

Thanks Herbs.  Works here with either lib -> lib64 or lib64 -> lib.

Bug #111877 is a duplicate of this bug but I didn't close it cause I'm just an
AT and didn't think I should.  Plus there are a lot more details there than
here.

We don't want to depend on DEFAULT_ABI or LIBDIR_<ABI> or anything like that in
userland.

emul-linux-x86-xlibs should not install header files.  Does anyone know why
those are in there?  If I don't hear a good reason, I'm just going to remove
them.

Just committed emul-linux-x86-xlibs-7.0 which does not install any opengl
headers. Note that both nvidia-glx and eselect-opengl also installs header
files in lib32, although probably just the same ones that go in lib64.

Ok, closing... thanks herbs.

*** Bug 127390 has been marked as a duplicate of this bug. ***

*** Bug 129030 has been marked as a duplicate of this bug. ***

ok so this bug was resolved and fixed weeks ago but people are still being
affected by it because the fix is in the emul-linux-x86-xlibs-7.0 package,
and at least with the xorg-x11 ebuild that I tried merging last night 
there is no dependency which causes that package to want to get updated.
perhaps a !<emul-linux-x86-xlibs-7.0 
dependency should be added to the modular x ebuilds or the eselect-opengl
ebuild.
(i forget if that is the right syntax)

*** Bug 129963 has been marked as a duplicate of this bug. ***