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 attachment 73418 [details, diff] 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 attachment 79409 [details, diff] 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 attachment 81175 [details] Detailed analysis of the problem with a patch that tells you if it a problem for you.
Created attachment 81190 [details, diff] 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. ***
