xorg-server won't compile, looks like missing glx dependancy. Master Google says that LX_SWAP_METHOD_OML extension needs GLX 1.3, but I couldn't find a package that would provide it. i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include -I../../include -I../../include -I../../include -I../../GL/include -DHAVE_DIX_CONFIG_H -I/var/tmp/portage/xorg-server-0.99.2-r1/work/Mesa-6.3.2/include -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -march=pentium3 -O2 -pipe -fomit-frame-pointer -MT glxcmds.lo -MD -MP -MF .deps/glxcmds.Tpo -c glxcmds.c -fPIC -o .libs/glxcmds.o i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include -I../../include -I../../include -I../../include -I../../GL/include -DHAVE_DIX_CONFIG_H -I/var/tmp/portage/xorg-server-0.99.2-r1/work/Mesa-6.3.2/include -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -march=pentium3 -O2 -pipe -fomit-frame-pointer -MT glxcmdsswap.lo -MD -MP -MF .deps/glxcmdsswap.Tpo -c glxcmdsswap.c -fPIC -o .libs/glxcmdsswap.o glxcmds.c: In function `DoGetFBConfigs': glxcmds.c:1105: error: `GLX_SWAP_METHOD_OML' undeclared (first use in this function) glxcmds.c:1105: error: (Each undeclared identifier is reported only once glxcmds.c:1105: error: for each function it appears in.) Reproducible: Always Steps to Reproduce: 1. migrate to modular xorg 2. unmask packages 3. emerge xorg-server Actual Results: emerge breaks, as shown above. Expected Results: it should build cleanly. tool bzd # emerge info Portage 2.0.53_rc7 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.13-gentoo-r4 i686) ================================================================= System uname: 2.6.13-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 1.70GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo" LANG="pl_PL.utf8" LC_ALL="pl_PL.utf8" LINGUAS="pl" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/overlay/bmg-main" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acl alsa apache2 apm arts audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl eds emboss encode esd ethereal exif expat fam flac foomaticdb fortran gdbm gif gnome gnutls gpm gstreamer gtk gtk2 hal imagemagick imlib ipv6 java jpeg lcms ldap libg++ libwww mad mikmod mmx mng mono motif mozilla moznocompose moznoirc moznomail mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pcre pdflib perl png python quicktime readline sdl slang snmp spell sse ssl svg svga tcpd tetex tiff truetype truetype-fonts type1-fonts udev usb vorbis wmf xine xml2 xv xvid zlib linguas_pl userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
Which version of xorg-server is this? You cut around that part of the error. Also, which versions of mesa and glproto do you have installed?
(In reply to comment #1) > Which version of xorg-server is this? You cut around that part of the error. Nevermind this part, I see it's in the subject.
(In reply to comment #1) > Which version of xorg-server is this? I've tried 0.99.2-r1 and todays 0.99.2-r2 - both behave the same. > Also, which versions of mesa and glproto do you have installed? [ebuild R ] x11-proto/glproto-1.4.1 [ebuild U ] media-libs/mesa-6.4 [6.3.2-r1]
tool bzd # grep GLX_SWAP /usr/include/GL/* /usr/include/GL/glxext.h:#define GLX_SWAP_METHOD_OML 0x8060 /usr/include/GL/glxext.h:#define GLX_SWAP_EXCHANGE_OML 0x8061 /usr/include/GL/glxext.h:#define GLX_SWAP_COPY_OML 0x8062 /usr/include/GL/glxext.h:#define GLX_SWAP_UNDEFINED_OML 0x8063 Hmm, seems like I have the necessary headers installed, but somehow build process doesn't use it.
Try upgrading your mesa, then re-run opengl-update xorg-x11.
(In reply to comment #5) > Try upgrading your mesa, then re-run opengl-update xorg-x11. I've already tried that, but I'm having problems installing the deps for mesa - openmotif should probably depend on libXp, since it needs headers from it, but libXp doesn't build either. I'll look more into it and send more info.
USE=-motif emerge mesa
(In reply to comment #7) > USE=-motif emerge mesa Upgrading Mesa helped. I've had some minor dep problems after that, but basically xorg-server builds fine now. It could be Mesa, but I guess I just should have switched to xorg opengl before I started compiling - I've used nvidia's glx from older ebuild.
Can you reproduce the problem with the new mesa by just opengl-update nvidia, then trying to compile xorg-server?
Is it possible to go totally without Mesa with the new modularized Xorg? All my needs are fulfilled by nvidia's implementation..
I get: glxcmds.c: In function '__glXBindSwapBarrierSGIX': glxcmds.c:1749: warning: cast to pointer from integer of different size glxcmds.c: In function '__glxQueryHyperpipeNetworkSGIX': glxcmds.c:1796: error: 'xGLXQueryHyperpipeNetworkSGIXReq' undeclared (first use in this function) glxcmds.c:1796: error: (Each undeclared identifier is reported only once glxcmds.c:1796: error: for each function it appears in.) glxcmds.c:1796: error: 'req' undeclared (first use in this function) glxcmds.c:1796: error: syntax error before ')' token glxcmds.c:1797: error: 'xGLXQueryHyperpipeNetworkSGIXReply' undeclared (first use in this function) glxcmds.c:1812: error: 'reply' undeclared (first use in this function) glxcmds.c:1825: error: 'sz_xGLXQueryHyperpipeNetworkSGIXReply' undeclared (first use in this function) glxcmds.c: In function '__glxDestroyHyperpipeConfigSGIX': glxcmds.c:1836: error: 'xGLXDestroyHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1836: error: 'req' undeclared (first use in this function) glxcmds.c:1837: error: syntax error before ')' token glxcmds.c:1838: error: 'xGLXDestroyHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1851: error: 'reply' undeclared (first use in this function) glxcmds.c:1863: error: 'sz_xGLXDestroyHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c: In function '__glxQueryHyperpipeConfigSGIX': glxcmds.c:1871: error: 'xGLXQueryHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1871: error: 'req' undeclared (first use in this function) glxcmds.c:1872: error: syntax error before ')' token glxcmds.c:1873: error: 'xGLXQueryHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1889: error: 'reply' undeclared (first use in this function) glxcmds.c:1904: error: 'sz_xGLXQueryHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c: In function '__glxHyperpipeConfigSGIX': glxcmds.c:1915: error: 'xGLXHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1915: error: 'req' undeclared (first use in this function) glxcmds.c:1916: error: syntax error before ')' token glxcmds.c:1917: error: 'xGLXHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1935: error: 'reply' undeclared (first use in this function) glxcmds.c:1949: error: 'sz_xGLXHyperpipeConfigSGIXReply' undeclared (first use in this function) On both -r1 and -r2, and with both nvidia and xorg-x11 headers.
Ah, that looks like the errors from a too-old glproto.
That's weird, I have the latest portage will give me on ~amd64: These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] x11-proto/glproto-1.4.1
(In reply to comment #13) > That's weird, I have the latest portage will give me on ~amd64: Seems like eselect-opengl links GL headers from the lib32 directory. I don't know where those came from, but they are older than the lib64 versions from glproto. I solved this by simply deleting the /usr/lib32/opengl directory and re-running eselect opengl xorg-x11 - just a quick hack until eselect-opengl gets fixed...
(In reply to comment #9) > Can you reproduce the problem with the new mesa by just opengl-update nvidia, > then trying to compile xorg-server? Yes. Emerge fails after opengl-update nvidia. I use 1.0.7174 nvidia's binary drivers, because latest version does not support my old Riva TNT2.
hmm... this results from the order in which eselect returns the multilib lib directories... but still... what is installing the headers into /usr/lib32/...?
*** Bug 113848 has been marked as a duplicate of this bug. ***
This bug is still not fixed in new xorg release (xorg-server-0.99.4-r1), I guess xorg-server ebuild should force opengl-update xorg-x11 mode. I've changed the summary back to original, since it's really not related to lib32 directory (my workstation is old Pentium III).
*** Bug 114791 has been marked as a duplicate of this bug. ***
Does this relate to this also? xorg-server-0.99.4-r2 release (all 0.99.4 releases IMHO) breaks fixed fonts (not importand) and does not play nice with nvidia on amd64 with nvidia, it compiles though. It "insists" on the wrong libglx.so: (II) LoadModule: "glx" (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 6.99.99.903, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (==) Using config file: "/etc/X11/xorg.conf" (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X (EE) NVIDIA(0): log file that the GLX module has been loaded in your X (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If (EE) NVIDIA(0): you continue to encounter problems, Please try (EE) NVIDIA(0): reinstalling the NVIDIA driver. No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 4294967295 Or does this belong to the new nvidia-8xxx release? I should try that also...
Oops! I patched eselect-opengl like http://bugs.gentoo.org/attachment.cgi?id=73945 and reemerged eselect eselect-opengl nvidia-glx glproto mesa xorg-server (brute force, yes ;)) and e voila: (II) LoadModule: "glx" (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.8174 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.1
Does xorg-server-1.0.0 with compile for anyone using nvidia-glx-1.0.7174-r5? Switching to xorg-x11 opengl is the only solution?
Nevermind 'with' :]
Jeremy: It seems to me that opengl.eselect is depending on a special order of items in the output of multilib.bash:list_libdirs().
Seems to be fixed in xorg-server-1.0.0, thanks :)
(In reply to comment #25) > Seems to be fixed in xorg-server-1.0.0, thanks :) ...but it works only with latest nvidia-drivers. Older nvidia-glx ebuilds (1.0.7174) cause the same problems with glxcmds.c. Unfortunately, latest drivers don't support older cards, like Riva TNT2 (on my other box I had to switch to xorg opengl) - so I guess it will be safer to always switch to xorg opengl.
(In reply to comment #26) > (In reply to comment #25) > > Seems to be fixed in xorg-server-1.0.0, thanks :) > > ...but it works only with latest nvidia-drivers. Sorry, no, it won't work here. I tried with xorg-server-1.0.1, nvidia-drivers 1.0.8178, latest glproto. (on ~amd64) I've got the same errors as comment #11. I'm going to try comment #14. cheers
(In reply to comment #27) > Sorry, no, it won't work here. I tried with xorg-server-1.0.1, nvidia-drivers > 1.0.8178, latest glproto. (on ~amd64) Solved following Comment #21. (modifications of /usr/share/eselect/libs/multilib.bash ) Thanks.
(In reply to comment #28) > (In reply to comment #27) > > Sorry, no, it won't work here. I tried with xorg-server-1.0.1, nvidia-drivers > > 1.0.8178, latest glproto. (on ~amd64) > > Solved following Comment #21. (modifications of > /usr/share/eselect/libs/multilib.bash ) > > Thanks. > I also had this problem and comment 21 also solved it.
None of these solutions seem to work for me. Here's the error message: glxcmds.c: In function `__glXBindSwapBarrierSGIX': glxcmds.c:1749: warning: cast to pointer from integer of different size glxcmds.c: In function `__glxQueryHyperpipeNetworkSGIX': glxcmds.c:1796: error: `xGLXQueryHyperpipeNetworkSGIXReq' undeclared (first use in this function) glxcmds.c:1796: error: (Each undeclared identifier is reported only once glxcmds.c:1796: error: for each function it appears in.) glxcmds.c:1796: error: `req' undeclared (first use in this function) glxcmds.c:1796: error: parse error before ')' token glxcmds.c:1797: error: `xGLXQueryHyperpipeNetworkSGIXReply' undeclared (first use in this function) glxcmds.c:1812: error: `reply' undeclared (first use in this function) glxcmds.c:1825: error: `sz_xGLXQueryHyperpipeNetworkSGIXReply' undeclared (first use in this function) glxcmds.c: In function `__glxDestroyHyperpipeConfigSGIX': glxcmds.c:1836: error: `xGLXDestroyHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1836: error: `req' undeclared (first use in this function) glxcmds.c:1837: error: parse error before ')' token glxcmds.c:1838: error: `xGLXDestroyHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1851: error: `reply' undeclared (first use in this function) glxcmds.c:1863: error: `sz_xGLXDestroyHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c: In function `__glxQueryHyperpipeConfigSGIX': glxcmds.c:1871: error: `xGLXQueryHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1871: error: `req' undeclared (first use in this function) glxcmds.c:1872: error: parse error before ')' token glxcmds.c:1873: error: `xGLXQueryHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1889: error: `reply' undeclared (first use in this function) glxcmds.c:1904: error: `sz_xGLXQueryHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c: In function `__glxHyperpipeConfigSGIX': glxcmds.c:1915: error: `xGLXHyperpipeConfigSGIXReq' undeclared (first use in this function) glxcmds.c:1915: error: `req' undeclared (first use in this function) glxcmds.c:1916: error: parse error before ')' token glxcmds.c:1917: error: `xGLXHyperpipeConfigSGIXReply' undeclared (first use in this function) glxcmds.c:1935: error: `reply' undeclared (first use in this function) glxcmds.c:1949: error: `sz_xGLXHyperpipeConfigSGIXReply' undeclared (first use in this function) make[2]: *** [glxcmds.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include -I../../include -I../../include -I../../include -I../../GL/include -I../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -I/home/tmp/portage/xorg-server-1.0.1-r2/work/Mesa-6.4.1/include -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -I../../lbx -O2 -mtune=k8 -pipe -fomit-frame-pointer -MT glxfb.lo -MD -MP -MF .deps/glxfb.Tpo -c glxfb.c -fPIC -DPIC -o .libs/glxfb.o x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include -I../../include -I../../include -I../../include -I../../GL/include -I../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -I/home/tmp/portage/xorg-server-1.0.1-r2/work/Mesa-6.4.1/include -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -I../../lbx -O2 -mtune=k8 -pipe -fomit-frame-pointer -MT glxcmdsswap.lo -MD -MP -MF .deps/glxcmdsswap.Tpo -c glxcmdsswap.c -fPIC -DPIC -o .libs/glxcmdsswap.o x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include -I../../include -I../../include -I../../include -I../../GL/include -I../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -I/home/tmp/portage/xorg-server-1.0.1-r2/work/Mesa-6.4.1/include -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -I../../lbx -O2 -mtune=k8 -pipe -fomit-frame-pointer -MT glximports.lo -MD -MP -MF .deps/glximports.Tpo -c glximports.c -fPIC -DPIC -o .libs/glximports.o make[2]: Leaving directory `/home/tmp/portage/xorg-server-1.0.1-r2/work/xorg-server-1.0.1/GL/glx' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tmp/portage/xorg-server-1.0.1-r2/work/xorg-server-1.0.1/GL' make: *** [all-recursive] Error 1 !!! ERROR: x11-base/xorg-server-1.0.1-r2 failed. Call stack: ebuild.sh, line 1894: Called dyn_compile ebuild.sh, line 941: Called src_compile ebuild.sh, line 1609: Called x-modular_src_compile x-modular.eclass, line 246: Called x-modular_src_make Here's the emerge --info Portage 2.1_pre4-r1 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r5 x86_64) ================================================================= System uname: 2.6.14-gentoo-r5 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Gentoo Base System version 1.6.14 ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -mtune=k8 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -mtune=k8 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/ ftp://gentoo.risq.qc.ca/ ftp://gentoo.agsn.ca/ http://gentoo.mirrored.ca/ ftp://gentoo.mirrored.ca/ http://gentoo.osuosl.org/ ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/home/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa amd64 avi berkdb bitmap-fonts cdr crypt cups dbus divx4linux doc dri dvd dvdr eds emboss encode foomaticdb fortran gif gnome gpm gstreamer gtk gtk2 gtkhtml hal imlib ipv6 java jpeg kde lzw lzw-tiff mp3 mpeg ncurses nls nocd nptl nptlonly nsplugin offensive oggvorbis opengl oss pam pcre pdflib perl png python qt quicktime readline sdl spell ssl tcpd tiff truetype-fonts type1-fonts unicode usb userlocales xpm xv zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux userland_GNU video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS
Just a note: I finally got mine working by making the following links in /usr/include/GL/ and leaving nvidia as my glx. gl.h -> //usr/lib32/opengl/nvidia/include/gl.h glext.h -> //usr/lib32/opengl/global/include/glext.h glxext.h -> //usr/lib32/opengl/global/include/glxext.h glxmd.h -> /usr/lib/opengl/xorg-x11/include/glxmd.h glxproto.h -> /usr/lib/opengl/xorg-x11/include/glxproto.h glxtokens.h -> /usr/lib/opengl/xorg-x11/include/glxtokens.h NOTE: Possibly related: Using kernel 2.6.14-gentoo-r5 led to:Jan 31 17:26:58 ShadowAerie Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds). Jan 31 17:26:58 ShadowAerie Hangcheck: Using monotonic_clock(). Jan 31 17:43:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 17:46:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 17:49:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 17:52:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 17:55:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 17:58:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:01:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:04:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:07:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:10:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:13:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:16:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:19:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:22:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:25:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:28:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:31:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:34:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:37:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:40:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:43:58 ShadowAerie Hangcheck: hangcheck value past margin! Jan 31 18:46:58 ShadowAerie Hangcheck: hangcheck value past margin! This was solved(hopefully) by upgrading to 2.6.15-gentoo-r1. Hope this helps.
Could someone test if setting the USE flag 'dlloader' and recompiling nvidia-glx solves the compile problem with xorg-server?
(In reply to comment #31) Not sure if this still falls under this glitch, or whether I should open a new bug but here goes. gdm is called on boot up, and the Nvidia flash page appears, then the normal Gnome boot-up occurs. Everything appears to be working.. Try to run any programs that depend on GLX and they fail saying: Could not load OpenGL library or Xlib: extension "GLX" missing on display ":0.0". I did a grep of xorg-conf and the glx option is enabled. I also did a grep of the xorg.0.log and I found this EE: (EE) Failed to load module "glx" (module does not exist, 0) (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X (EE) NVIDIA(0): log file that the GLX module has been loaded in your X (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If (EE) NVIDIA(0): you continue to encounter problems, Please try (EE) NVIDIA(0): reinstalling the NVIDIA driver. I've emerge -C nvidia-kernel nvidia-glx && emerge nvidia-kernel nvidia-glx && eselect opengl set nvidia (and on the odd chance eselect wasn't working, I also re-tried doing opengl-update nvidia). As it stands, the error is still occuring and as I figure it out, I'll post back.
I use this script as a workaround for a while now to get xorg-server compiled and glx working in X: #!/bin/bash rm /usr/include/GL/gl.h rm /usr/include/GL/glx.h rm /usr/include/GL/glxmd.h rm /usr/include/GL/glxproto.h rm /usr/include/GL/glxtokens.h rm /usr/include/GL/glxext.h rm /usr/include/GL/glext.h ln -s /usr/lib/opengl/nvidia/include/gl.h /usr/include/GL/gl.h ln -s /usr/lib/opengl/nvidia/include/glx.h /usr/include/GL/glx.h ln -s /usr/lib/opengl/xorg-x11/include/glxmd.h /usr/include/GL/glxmd.h ln -s /usr/lib/opengl/xorg-x11/include/glxproto.h /usr/include/GL/glxproto.h ln -s /usr/lib/opengl/xorg-x11/include/glxtokens.h /usr/include/GL/glxtokens.h ln -s /usr/lib/opengl/xorg-x11/include/glxext.h /usr/include/GL/glxext.h ln -s /usr/lib/opengl/xorg-x11/include/glext.h /usr/include/GL/glext.h Hope the issues with eselect are fixed soon, don't have any problems on non multilib systems though.
I forgot to say that /lib is a symlink to /lib64 of course but i think this is also default: lrwxrwxrwx 1 root root 5 19. Dez 18:56 lib -> lib64 (In reply to comment #34) > I use this script as a workaround for a while now to get xorg-server compiled > and glx working in X: > > #!/bin/bash > rm /usr/include/GL/gl.h > rm /usr/include/GL/glx.h > rm /usr/include/GL/glxmd.h > rm /usr/include/GL/glxproto.h > rm /usr/include/GL/glxtokens.h > rm /usr/include/GL/glxext.h > rm /usr/include/GL/glext.h > > ln -s /usr/lib/opengl/nvidia/include/gl.h /usr/include/GL/gl.h > ln -s /usr/lib/opengl/nvidia/include/glx.h /usr/include/GL/glx.h > ln -s /usr/lib/opengl/xorg-x11/include/glxmd.h /usr/include/GL/glxmd.h > ln -s /usr/lib/opengl/xorg-x11/include/glxproto.h /usr/include/GL/glxproto.h > ln -s /usr/lib/opengl/xorg-x11/include/glxtokens.h /usr/include/GL/glxtokens.h > ln -s /usr/lib/opengl/xorg-x11/include/glxext.h /usr/include/GL/glxext.h > ln -s /usr/lib/opengl/xorg-x11/include/glext.h /usr/include/GL/glext.h > > Hope the issues with eselect are fixed soon, don't have any problems on non > multilib systems though. >
(In reply to comment #35) > I forgot to say that /lib is a symlink to /lib64 of course but i think this is > also default: > lrwxrwxrwx 1 root root 5 19. Dez 18:56 lib -> lib64 Mine is the exact opposite. /lib64 is a symlink to lib lrwxrwxrwx 1 root root 3 Mar 10 2005 lib64 -> lib That could explain the problem.. It's reversed the linkages somewhere along the line.
(In reply to comment #32) > Could someone test if setting the USE flag 'dlloader' and recompiling > nvidia-glx solves the compile problem with xorg-server? It doesn't help me. (In reply to comment #34) >#!/bin/bash >rm /usr/include/GL/gl.h >rm /usr/include/GL/glx.h >rm /usr/include/GL/glxmd.h >rm /usr/include/GL/glxproto.h >rm /usr/include/GL/glxtokens.h >rm /usr/include/GL/glxext.h >rm /usr/include/GL/glext.h > >ln -s /usr/lib/opengl/nvidia/include/gl.h /usr/include/GL/gl.h >ln -s /usr/lib/opengl/nvidia/include/glx.h /usr/include/GL/glx.h >ln -s /usr/lib/opengl/xorg-x11/include/glxmd.h /usr/include/GL/glxmd.h >ln -s /usr/lib/opengl/xorg-x11/include/glxproto.h /usr/include/GL/glxproto.h >ln -s /usr/lib/opengl/xorg-x11/include/glxtokens.h /usr/include/GL/glxtokens.h >ln -s /usr/lib/opengl/xorg-x11/include/glxext.h /usr/include/GL/glxext.h >ln -s /usr/lib/opengl/xorg-x11/include/glext.h /usr/include/GL/glext.h This does, though.
*** Bug 122286 has been marked as a duplicate of this bug. ***
(In reply to comment #0) "eselect opengl set xorg-x11" and "emerge -e xorg-x11" It made xorg-server compile without errors. I had the same errors as comment #1. I don't know if both commands in nessesary.
*** Bug 122714 has been marked as a duplicate of this bug. ***
Same error messages as comment #11 But solution from #34 does not work for amd64 users (at least not for me). From the forums, a modified version is : #!/bin/bash rm /usr/include/GL/gl.h rm /usr/include/GL/glx.h rm /usr/include/GL/glxmd.h rm /usr/include/GL/glxproto.h rm /usr/include/GL/glxtokens.h rm /usr/include/GL/glxext.h rm /usr/include/GL/glext.h ln -s /usr/lib64/opengl/xorg-x11/include/gl.h /usr/include/GL/gl.h ln -s /usr/lib64/opengl/xorg-x11/include/glx.h /usr/include/GL/glx.h ln -s /usr/lib64/opengl/xorg-x11/include/glxmd.h /usr/include/GL/glxmd.h ln -s /usr/lib64/opengl/xorg-x11/include/glxproto.h /usr/include/GL/glxproto.h ln -s /usr/lib64/opengl/xorg-x11/include/glxtokens.h /usr/include/GL/glxtokens.h ln -s /usr/lib64/opengl/xorg-x11/include/glxext.h /usr/include/GL/glxext.h ln -s /usr/lib64/opengl/xorg-x11/include/glext.h /usr/include/GL/glext.h That one worked for me.
(In reply to comment #41) I'm on amd64, so it does work (at least for me) ;) I used the one from the forums as a base since that one doesn't respect the nvidia gl.h and glx.h and didn't work for me.
As someone who is familiar with packaging the nVidia and ATI drivers for another distro, I object to having their headers used for building. The xorg-x11 libGL headers should always be used. It improves the consistency situation and prevents users from having to recompile everything GL when they switch video cards. There is simply no reason for it. The ATI and nVidia GL libraries can be dynamically loaded regardless of what headers and libraries were used to compile -- if this were not the case, the binary distributions would be screwed.
*** Bug 123255 has been marked as a duplicate of this bug. ***
This is a duplicate of Bug #109922 guys. :)
I had the same error as comment #1 I'm not using 64bit odd things ;) ... i just have a 32bit proc. First, i modified the symlinks for the include files as proposed in comment #34. It solved the declaration of GLX_SWAP_METHOD_OML. Then another error occured : GLX_COLOR_INDEX_TYPE_SGIX undeclared ... in another c file. After doing "eselect opengl set xorg-x11" it solved the declaration problem, and xorg-x11 compiled correctly. Performing the eselect command change the include links this way : from : gl.h -> /usr/lib/opengl/nvidia/include/gl.h to : gl.h -> /usr/lib/opengl/xorg-x11/include/gl.h from : glext.h -> /usr/lib/opengl/xorg-x11/include/glext.h to : glext.h -> /usr/lib/opengl/global/include/glext.h from : glx.h -> /usr/lib/opengl/nvidia/include/glx.h to : glx.h -> /usr/lib/opengl/xorg-x11/include/glx.h from : glxext.h -> /usr/lib/opengl/xorg-x11/include/glxext.h to : glxext.h -> /usr/lib/opengl/global/include/glxext.h glxmd.h,glxproto.h,glxtokens.h symlinks are unchanged by the eselect command. Hope this helps ...
When is the real source of this bug ever going to be fixed? The cause of this problem is eselect relies on the 32bit version of the glx header files. However, the real problem is the 32bit libraries used in the x86_64 arch are all binaries and they lag behind the real packages often causing problems. So, the real cause of this problem is 32bit packages not being updated properly (eselect probably shouldn't rely on the 32bit headers, since they are so unpredictable) I have no silver bullet to fix the problem, but it seems that on dual arch platforms, portage should keep to seperate dep trees, and update them simlultaneously.
Just to clarify: All the people with problems due to older opengl headers in lib32, that's a separate issue and is covered by bug 109922 which is fixed with the latest emul-linux-x86-xlibs. The only remaining issue here afaics is that of the bug reporter Artur, see comments #26
(In reply to comment #41) > Same error messages as comment #11 > > But solution from #34 does not work for amd64 users (at least not for me). > From the forums, a modified version is : > > #!/bin/bash > rm /usr/include/GL/gl.h > rm /usr/include/GL/glx.h > rm /usr/include/GL/glxmd.h > rm /usr/include/GL/glxproto.h > rm /usr/include/GL/glxtokens.h > rm /usr/include/GL/glxext.h > rm /usr/include/GL/glext.h > > ln -s /usr/lib64/opengl/xorg-x11/include/gl.h /usr/include/GL/gl.h > ln -s /usr/lib64/opengl/xorg-x11/include/glx.h /usr/include/GL/glx.h > ln -s /usr/lib64/opengl/xorg-x11/include/glxmd.h /usr/include/GL/glxmd.h > ln -s /usr/lib64/opengl/xorg-x11/include/glxproto.h /usr/include/GL/glxproto.h > ln -s /usr/lib64/opengl/xorg-x11/include/glxtokens.h /usr/include/GL/glxtokens.h > ln -s /usr/lib64/opengl/xorg-x11/include/glxext.h /usr/include/GL/glxext.h > ln -s /usr/lib64/opengl/xorg-x11/include/glext.h /usr/include/GL/glext.h > > That one worked for me. > That worked for me too.
I' ve always used NVIDIA-Linux-x86-1.0-7174-pkg1.run, and never had that problem
*** Bug 127858 has been marked as a duplicate of this bug. ***
opengl-update xorg-x11 works for me. Im in a AthlonXp 1.4Ghz 256MB last kernel GeForce 2 GTS whit 1.0.7174 drivers. But i like to know about the impacts of use opengl-update xorg-x11 instead opengl-update nvidia. Could this afect my card's performance badly?
If you need to use 'eselect opengl xorg' to compile something, then please file a bug, so we can look into it and pester nVidia to fix their headers. If you build with xorg, and then switch to nvidia to run, then you will be perfectly fine. It's the runtime linkage that is the concern. In fact in a future version of eselect-opengl, I'll probably add a feature to set just headers or just runtime, so you can have the xorg headers used to compile and use the nvidia runtime and just ignore this headache (yeah, it's a hack, and the best thing would be getting nVidia to fix their headers) Thanks for verifying this is working for you.
*** Bug 128396 has been marked as a duplicate of this bug. ***
*** Bug 141389 has been marked as a duplicate of this bug. ***
