the declaration of void GLAPI glMultiDrawArrays (GLenum mode, const GLint *first, const GLsizei *count, GLsizei primcount); in gl.h contains 2 consts before const GLint *first and const GLsizei that you don't find in the glext.h extern declaration from the X11 header file which looks like this from my xfree-4.3.0-r3 ebuild: GLAPI void APIENTRY glMultiDrawArrays (GLenum, GLint *, GLsizei *, GLsizei); if sources (like e.g. media-libs/coin) define the following variable #define GL_GLEXT_PROTOTYPE 1 in their headers the compile breaks. removing the consts from the declaration in gl.h fixes the problem. i suggest to create a patch for this that removes the additional consts similar to what has been done for the missing typedef XID GLXPbufferSGIX; of glx.h in nvidia-glx-1.0.5328-defines.patch and report this incident to NVidia so that they can fix it in their next release. thx, tamer. Reproducible: Always Steps to Reproduce: 1. compile the following little program: tamer@walpurgis ~ $ cat test.c #define GL_GLEXT_PROTOTYPES 1 #include <GL/gl.h> int main(int argc, char *argv[]) { return 0; } Actual Results: In file included from test.c:2: /usr/include/GL/gl.h:1731: conflicting types for `glMultiDrawArrays' /usr/include/GL/glext.h:2618: previous declaration of `glMultiDrawArrays' Portage 2.0.49-r20 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.4.22-gentoo-r2) ================================================================= System uname: 2.4.22-gentoo-r2 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.4.3.10 distcc 2.11.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache distcc notitles sandbox userpriv" GENTOO_MIRRORS="http://gentoo.inode.at/" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acpi alsa apache2 apm arts avi berkdb bindist bonobo cdr crypt cups curl doc emacs encode esd faad fastcgi fbcon ffmpeg foomaticdb gd gdbm gif glut gnome gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imlib jack java jikes joystick jpeg junit kde ldap libg++ libwww mad mbox mcal mikmod mmx mng motif mozilla mpeg mule nas ncurses nls oggvorbis openal opengl oss pam pdflib perl png postgres python qt quicktime readline ruby samba sasl scanner sdl slang slp spell sqlite sse ssl tcltk tcpd tetex tiff truetype unicode usb v4l videos wmf wxwindows x86 xinerama xml2 xmms xv zeo zlib"
Created attachment 23402 [details, diff] opengl-update.patch It is declared in nvidia's glext.h, but opengl-update doesn't look for glext.h when setting up symlinks. Patch /usr/sbin/opengl-update with this.
After patching, run it again. Hopefully that was understood. =)
Created attachment 23403 [details, diff] opengl-update.patch This is a better version, allowing for new includes in the future.
1. the glext.h that nvidia provides is broken (greets to their QA department). (find a patch and a new revised nvidia-glx ebuild for it attached) 2. your opengl-update fix is good but not 100% clean, because if one switches forth and back the glext.h from xfree would have been removed as it is not saved in /usr/lib/opengl/xfree/include. imho for the future it's better and just to be on the safe side to install all GL headers from xfree into /usr/lib/opengl/xfree/include and symlink them from /usr/X11R6/include/GL/. the reason for that is that different to previous versions nvidia provides a glext.h in version 5328. also for other future binary only drivers (like ATI's Radeon drivers) that could then be switched to by opengl-update you never know for sure which headers they would provide. (find a patch that shows the difference and a new revised ebuild for it attached). cheers, tamer.
Created attachment 23472 [details, diff] a patch to fix the malformed declarations of the glext.h header file provided by nvidia
Created attachment 23474 [details] nvidia-glx-1.0.5328-r2.ebuild
Created attachment 23476 [details, diff] shows the differences between the rev3 and rev4 ebuild
Created attachment 23477 [details] xfree-4.3.0-r4.ebuild
of course the glMultiDrawArrays() in gl.h is still declared in a wrong fashion... revised previous patches and renamed complete patch file to nvidia-glx-1.0.5328-glheader.patch.
Created attachment 23481 [details, diff] nvidia-glx-1.0.5328-glheader.patch
Created attachment 23482 [details] nvidia-glx-1.0.5328-r2.ebuild
actually i just found out that the glext.h from nvidia is much older and probably erroneously putten in their package. so i suggest again to just patch the broken nvidia gl.h as i hinted in my first comment and get on with life. keep everything as before (no opengl-update patch yet) as it otherwise would get too involved. probably leave the other proposed proper fixes for the next major X release in order not to annoy users by having them to rebuild X because of such a minor issue. (attached revised patch for gl.h only) cheers, tamer.
Created attachment 23493 [details, diff] nvidia-glx-1.0.5328-glheader.patch
Installing gl*.h from xfree to /usr/lib/opengl/xfree/include/ is a good idea. We should start doing that. How did you find out glext.h from nvidia is much older and probably wrongly included? And much older compared to what?
glext.h just lists all possible declarations for opengl extensions and which is maintained by SGI on their OpenGL extensions page at http://oss.sgi.com/projects/ogl-sample/registry/. the most recent file can be obtained from http://oss.sgi.com/projects/ogl-sample/ABI/glext.h. usually glx OpenGL programmers look at this file for a reference to get the function signatures and would have to resolve and check for the availability of the functions at runtime as the context could be possibly run remotely on another X11 server where the GL driver of that machine possibly doesn't feature the extension or you compile it on one machine and run the binary on another with a different graphics board. so configure checks at build time for most of the functions declared in this file would not make a lot of sense so or so. anyways the glext.h header file has a GL_GLEXT_VERSION preprocessor define. Different to xfree which grabs the most recent version of the file at the time of their release - NVidia seems to have provided its very own version in this driver release. if you look into their previous driver version 4496 they didn't provide one. also apart from the GL_GLEXT_VERSION their copyright header is dated back to 2001 for the year and most importantly they had a wrong declaration saying boolean instead of GLboolean in one of their parameters where i then concluded that they must have erroneously provided it or at least the wrong one as missing const's an older compiler would have probably munched with a warning but a boolean instead of GLboolean would make it not possible to compile as it is obviously a typo and they nowhere typedef'd it. in short the version that comes with X11 has GL_GLEXT_VERSION 17 whereas NVidia's has GL_GLEXT_VERSION 6. i honestly believe that this incident should be reported to NVidia as they didn't seem to have done a proper job in testing before they released this version. they should definitely fix this for their next release and we should not expose or provide the older glext.h for OpenGL programs anyways and keep the more recent glext.h which comes with X11 as it worked fine previously for other OpenGL programs that just saw this one, too! what do you think? tamer.
OK, here's my tentative 'big picture' plan: 1) Install include/GL/* to /usr/lib/opengl/xfree/include/. 2) Fix opengl-update to resymlink anything that exists instead of a set list. Other than that, we'll start applying your patch to the nvidia header.
Spanky or Azarah, any input on comment #16?
works for me ... as long as the final set has all the files ;)
ok, sounds like a .plan to me! just to make sure that we understand each other correctly. you should then patch the headers with the nvidia-glx-1.0.5328-glheader.patch from 2004-01-09 8:50 as it contains fixes for glext.h, too - which i left out in the last version i attached. still i would opt very much so to not install the glext.h file that nvidia provides (which is imho broken beyond any recognition) in favor for the correct and more recent X11R6 glext.h version. in cleartext: don't install the glext.h one from the nvidia driver ebuild. cheers and thx for the good work on those ebuilds, tamer.
have you checked out the very latest release nvidia put out ? Bug 39521 has info about it ... i wonder if anything has been changed and the patches are not needed or need to be updated
ah, thx for the hint! :) didn't notice that they already released a new version... will check it out tomorrow and tell you how it went and if they hopefully fixed something (would save us a lot of hassle...)! cheers, tamer.
hi SpanKY! unfortunately, the same situation for their newest drivers... :( i should have got over it and reported this to nvidia. *headbang* i will do so now on their forums. cheers, tamer.
posted it, find it at: http://www.nvnews.net/vbulletin/showthread.php?s=&threadid=24252 let's see what comes out of this.
*** Bug 43176 has been marked as a duplicate of this bug. ***
*** Bug 44821 has been marked as a duplicate of this bug. ***
OK just let me clarify before I change anything glext.h should be provided by virtual/x11 --> which will install it to /usr/X11R6/include/GL/glext.h gl.h from nvidia should be patched as supplied above for API consistency and nvidias' glext.h should be discarded. opengl-update should work as it does currently only creating symlinks for certain files, this way we can safely leave the glext.h file in /usr/X11R6/include/GL/glext.h and simply maintain it in each or any profile. (This is preferable in my eyes otherwise opengl-update will need to take parts from the xfree/xorg-x11 implementation when updating the nvidia profile which is yuck). What about ati opengl stuff where will that stand in this mixture?
OK ati-drivers doesnt supply a glext.h so have removed supply from nvidia-glx in the ~x86 and ~amd64 ebuilds. The patch to fix up gl.h with the x11 glext.h api has also be included into cvs. Please be aware that glext.h should reside in /usr/X11R6/include/GL/glext.h not as a symlink. Closing
