Summary: | xorg-server-0.99.4-r2 fails: GL/glxproto.h: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jaak Ristioja <jaak> |
Component: | Current packages | Assignee: | Jeremy Huddleston (RETIRED) <eradicator> |
Status: | VERIFIED DUPLICATE | ||
Severity: | critical | CC: | amd64, mpytasz, VValdo, x11 |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 112004 | ||
Attachments: | Mesa-6.4.1-r1 compilation output |
Description
Jaak Ristioja
2005-12-09 14:51:43 UTC
I can confirm this bug with my x86 machine, so its not AMD64 specific. (In reply to comment #1) > I can confirm this bug with my x86 machine, so its not AMD64 specific. Oh, and its specific to the +dri flag. Created attachment 75234 [details]
Mesa-6.4.1-r1 compilation output
This is probably related to the bug at hand.
I found out, that what caused the problem, was emul-linux-x86-xlibs-2.2-r1, which ran "eselect opengl set --use-old", which in turn somehow managed to break the symlinks to link to emul-linux libraries in /usr/include/GL: lrwxrwxrwx 1 root root 39 Dec 23 16:16 gl.h -> /usr/lib32/opengl/xorg-x11/include/gl.h lrwxrwxrwx 1 root root 42 Dec 23 16:16 glext.h -> /usr/lib32/opengl/xorg-x11/include/glext.h lrwxrwxrwx 1 root root 40 Dec 23 16:16 glx.h -> /usr/lib32/opengl/xorg-x11/include/glx.h lrwxrwxrwx 1 root root 43 Dec 23 16:16 glxext.h -> /usr/lib32/opengl/xorg-x11/include/glxext.h lrwxrwxrwx 1 root root 42 Dec 23 16:16 glxmd.h -> /usr/lib32/opengl/xorg-x11/include/glxmd.h lrwxrwxrwx 1 root root 45 Dec 23 16:16 glxproto.h -> /usr/lib32/opengl/xorg-x11/include/glxproto.h lrwxrwxrwx 1 root root 46 Dec 23 16:16 glxtokens.h -> /usr/lib32/opengl/xorg-x11/include/glxtokens.h So one must manually relink them to the headers in /usr/lib64/opengl/xorg-x11/include/. I was unable to fix this by running "eselect opengl set xorg-x11". xorg-server-1.0.1.ebuild: switch_opengl_implem() { # Switch to the xorg implementation. # Use new opengl-update that will not reset user selected # OpenGL interface ... echo eselect opengl set --use-old ${OPENGL_DIR} } This DID RESET the symlinks thou, so again i had to RESET them myself during compilation. *** Bug 116501 has been marked as a duplicate of this bug. *** I can confirm the same problem. I'm manually relinking, and if I continue to have problems, I'll post them here. Here's what I did (in case anyone else wants to avoid retyping): eselect opengl set xorg-x11 cd /usr/include/GL rm gl.h ln -s /usr/lib64/opengl/xorg-x11/include/gl.h gl.h rm glext.h ln -s /usr/lib64/opengl/global/include/glext.h glext.h rm glx.h ln -s /usr/lib64/opengl/xorg-x11/include/glx.h glx.h rm glxext.h ln -s /usr/lib64/opengl/global/include/glxext.h glxext.h rm glxmd.h ln -s /usr/lib64/opengl/xorg-x11/include/glxmd.h glxmd.h rm glxproto.h ln -s /usr/lib64/opengl/xorg-x11/include/glxproto.h glxproto.h rm glxtokens.h ln -s /usr/lib64/opengl/xorg-x11/include/glxtokens.h glxtokens.h This is with xorg-server-1.0.1 (might want to update the summary) UPDATE: This seems to have worked, xorg-server compiled :) W > Here's what I did (in case anyone else wants to avoid retyping):
I just figured out, that one can save a lot of typing by using
ln -sf /usr/lib64/opengl/xorg-x11/* /usr/include/GL/
I noticed that you linked some files from /usr/lib64/opengl/global. I'm just wondering, but didn't glxext.h and glext.h exist in /usr/lib64/opengl/xorg-x11/?
I've been looking for /usr/lib32/opengl in etc (and some other places) to see why such symlinks are created in the first place. What I thought is if it was problem with eselect? Having edited /etc/env.d/03opengl which originally was: # Configuration file for eselect # This file has been automatically generated. LDPATH="/usr/lib32/opengl/xorg-x11/lib" OPENGL_PROFILE="xorg-x11" changing: LDPATH to "/usr/lib64/opengl/xorg-x11/lib" and running eselect set opengl xorg-x11 causes original file to restore. lib32 can be found in /usr/share/eselect/modules/opengl.eselect and it is said handle "specially" emul libs. Aren't just emul - libs too old? Also, what is this path used for anyway (env-update does not re-create symlinks...) ? Yes, this is a known problem with eselect. *** This bug has been marked as a duplicate of 109922 *** *** This bug has been marked as a duplicate of 109922 *** I suppose not only with eselect but with app-emulation/emul-linux-x86-xlibs as well ;) |