With opengl-update 1.8.1 and the latest nvidia driver (unmasked via package.keywords) installed along with xorg-x11, applications that need gtkglext can't be built if hte opengl-profile is set to "nvidia". apps fail top build wiht the following errors: /usr/include/gtkglext-1.0/gdk/gdkglglext.h:42: error: redefinition of `GLhalfNV' /usr/X11R6/include/GL/glext.h:2841: error: `GLhalfNV' previously declared here make: *** [3d_vetable.o] Error 1 Reproducible: Always Steps to Reproduce: 1. unmask opengl-update, nvidia-kernel/glx and xorg-x11 2. emerge world -uD 3. opengl-update nvidia attempt to compile and application that uses the gtkglext library Actual Results: /usr/include/gtkglext-1.0/gdk/gdkglglext.h:42: error: redefinition of `GLhalfNV' /usr/X11R6/include/GL/glext.h:2841: error: `GLhalfNV' previously declared here make: *** [3d_vetable.o] Error 1 Expected Results: make should have worked.. IT DOES work if the opengl profile is changed to xorg-x11. This stopped working with opengl-update 1.8 and nvidia drivers over the 6000 series. /etc/portage/package.keywords >=x11-base/xorg-x11-6.7.0 ~x86 >=x11-base/opengl-update ~x86 x11-terms/xterm ~x86 media-sound/jack-audio-connection-kit ~x86 media-plugins/xmms-jack ~x86 media-fonts/corefonts ~x86 x11-wm/enlightenment ~x86 x11-themes/ethemes ~x86 x11-themes/etheme-BlueSteel ~x86 x11-themes/etheme-BrushedMetal-Tigert ~x86 x11-themes/etheme-Ganymede ~x86 x11-themes/etheme-ShinyMetal ~x86 >=media-video/nvidia-kernel-1.0.6000 ~x86 >=media-video/nvidia-glx-1.0.6000 ~x86 >=media-video/nvidia-settings-1.0 ~x86 emerge --info Portage 2.0.50-r9 (default-x86-2004.2, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.7 -gentoo-r12) ================================================================= System uname: 2.6.7-gentoo-r12 i686 AMD Athlon(tm) MP Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-mp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2 /share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/ config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/shar e/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf /xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=athlon-mp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc sandbox" GENTOO_MIRRORS="ftp://mirrors.tds.net/gentoo http://mirror.datapipe.net/gentoo h ttp://mir.zyrianes.net/gentoo/" MAKEOPTS=" -j5 " PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acl alsa apm arts avi berkdb bonobo cdr crypt cups curl dga dvb dvd encode esd foomaticdb freetype gdbm ggi gif gnome gphoto2 gpm gtk gtk2 guile im lib jack java joystick jpeg kde libg++ libwww mad mikmod mmx motif mozilla mpeg mysql nas ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quickti me readline ruby samba scanner sdl slang spell ssl svga tcltk tcpd tetex truetyp e usb videos wmf x86 xft xml2 xmms xv zlib"
Try remerging nvidia-glx-1.0.6111 and do an opengl-update nvidia Problem persist?
Dave: prod See comment #1 (actually what its meant to mean is remerge nvidia-glx after syncing your tree)
the problem still exists. If the opengl profile is set to "nvidia", apps built that require gtkglext still barf on the redefinition of GLhalfNV. I think that this may be due to the fact that gtkglext is ALWAYS BUILT with the xorg-x11 profile and not the nvidia OpenGL profile.. I can't test it manually yet due to thermal issues with the system. (room temp is too high to run the main system)
Ok, I've removed all the stuff in the gtkglext-1.0.5 ebuild with regards to switching the OpenGL profile, switched my profile to Nvidia (using 6111 drivers) and gtkglext built just fine.. My application which previously WOULD NOT compile when in the nvidia opengl-profile (due to gtkglext being compiled against Xorg's GL implemenation) now compiles cleanly and no longer bitches... Ok here's what I see as the PROPER way to fix this issue: I think that since this ebuild is dependant on the OpenGL implementation and since more than 1 are allowed, that it should be built for EACH openGL implementation on the users system and the libraries/includes stored in /usr/lib/opengl/nvidia_or_xorg-x11 and switched in/out when opengl update is run. This would solve all the problems and make sure that the gtkglext is compiled/linked against the appropriate openGL headers/libs for each one. Please make these changes and apply them to the 1.0.5 (or 1.0.6) ebuilds.. The rest of the gentoo world will thank your for it.. ;)
opengl-update has one purpose -- to update the OpenGL implementation. Not to screw around with the rest of the system, updating various things that depend on certain implementations. That's the job of either a user or another tool. Although it would be optimal to just fix the OpenGL implementations to be properly interoperable.
well this bug still persists... On my box. I have nvidia (6629 drivers now). I compile gtkglext, it buil;ds and installs without dying, now I try and build my application that USES gtkglext, and it will NOT compile because gtkglext was built against a different set of GL header files were definitions are NOT the same... As I said before, since the GL implementations between Xorg and nvidia differ, that gtkglext should be built TWICE, once for each profile and it's conents installed into /usr/lib/opengl/<profile it was built against> this way opengl-update will move them into the proper locations (hopefully) when switching profiles and my (and any other ) GL program will compile no matter what OpenGL profile I'm in. It's NO longer possible to switch GL profiles when in X11 as starting a GL app after the profile switch causes X to abort. so what I have to do now, is to log out of X, switch the profile to xorg-x11, restart X, compile my app and if I want acceleration, I need to EXIT X11 AGAIN, switch profiles restart X and then run it. Having gtkglext build against BOTH GL profiles and install to /usr/lib/opengl/<appropriate profile> solves all problems in an elegant manner, and prevents having to tweak the X.org GL headers or nvidia GL headers (which may break OTHER applications) PLEASE consider making this change, as I see it as very doubtful that you will get the Xorg and nvidia GL implementations to line up to prevent the above issues. if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DXTHREADS -D_REENTRANT -DXUSE_ MTSAFE_API -pthread -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/in clude/libxml2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk -1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/ config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtkgle xt-1.0 -I/usr/lib/gtkglext-1.0/include -O2 -DDATA_DIR=\"/usr/local/share/MegaTun ix\" -DLOOKUPTABLE_DIR=\"LookupTables\" -DINTERROGATOR_DIR=\"Interrogator\" -DG UI_DIR=\"Gui\" -DREALTIME_MAP_DIR=\"RealtimeMaps\" -DGTK_DISABLE_COMPAT_H -DGDK_ DISABLE_DEPRECATED -D_MAJOR_=0 -D_MINOR_=6 -D_MICRO_=0 -Wall -O2 -MT 3d_vet able.o -MD -MP -MF ".deps/3d_vetable.Tpo" -c -o 3d_vetable.o 3d_vetable.c; \ then mv -f ".deps/3d_vetable.Tpo" ".deps/3d_vetable.Po"; else rm -f ".deps/3d_ve table.Tpo"; exit 1; fi In file included from /usr/include/gtkglext-1.0/gdk/gdkglglext.h:53, from ../include/3d_vetable.h:22, from 3d_vetable.c:20: /usr/include/gtkglext-1.0/gdk/glext/glext.h:1540:1: warning: "GL_RESTART_SUN" re defined In file included from /usr/X11R6/include/GL/gl.h:71, from /usr/include/gtkglext-1.0/gdk/gdkglglext.h:33, from ../include/3d_vetable.h:22, from 3d_vetable.c:20: /usr/X11R6/include/GL/glext.h:2215:1: warning: this is the location of the previ ous definition In file included from /usr/include/gtkglext-1.0/gdk/gdkglglext.h:53, from ../include/3d_vetable.h:22, from 3d_vetable.c:20: /usr/include/gtkglext-1.0/gdk/glext/glext.h:1541:1: warning: "GL_REPLACE_MIDDLE_ SUN" redefined In file included from /usr/X11R6/include/GL/gl.h:71, from /usr/include/gtkglext-1.0/gdk/gdkglglext.h:33, from ../include/3d_vetable.h:22, from 3d_vetable.c:20: /usr/X11R6/include/GL/glext.h:2216:1: warning: this is the location of the previ ous definition In file included from /usr/include/gtkglext-1.0/gdk/gdkglglext.h:53, from ../include/3d_vetable.h:22, from 3d_vetable.c:20: /usr/include/gtkglext-1.0/gdk/glext/glext.h:1542:1: warning: "GL_REPLACE_OLDEST_ SUN" redefined In file included from /usr/X11R6/include/GL/gl.h:71, from /usr/include/gtkglext-1.0/gdk/gdkglglext.h:33, from ../include/3d_vetable.h:22, from 3d_vetable.c:20: /usr/X11R6/include/GL/glext.h:2217:1: warning: this is the location of the previ ous definition In file included from /usr/include/gtkglext-1.0/gdk/gdkglglext.h:53, from ../include/3d_vetable.h:22, from 3d_vetable.c:20: /usr/include/gtkglext-1.0/gdk/glext/glext.h:3810: error: redefinition of `PFNGLC OLORSUBTABLEEXTPROC' /usr/X11R6/include/GL/glext.h:3223: error: `PFNGLCOLORSUBTABLEEXTPROC' previousl y declared here make: *** [3d_vetable.o] Error 1
Anyone interested in enhancing opengl-update to dynamically symlink whatever it finds in /usr/lib/opengl/$implementation? I think it's (at least mostly) hard-coded file-by-file now.
I may do it. (time permitting) does anyone else agree that the suggestion I made is worthy ?
Comments on the above?
OK for official record... We should do the dynamic linking, that makes sense... Now, as regards to the GL implementation incompatibilities... personally I feel that each gl providers implementation should be used, with as little changes as possible; however I think that opengl-update (this is an idea I havent had time, until now to develop) should dynamically CREATE gl.h and a blank glext.h from the set of symbols that are provided by the GL providers -- this doesnt solve incompatibilities ie the gktglext usage problem. Comments on this welcome... Now to the actual bug in question, installing gl implementation compiled files in each implementation has one serious flaw that being new implementations being installed (or non-backward compatible updates, which are rare though). This would probably lead to opengl-update actually being part of portage, for need to some package control. Personally thats a bit beyond its scope IMO. Given that im lead to believe that having a system wide gl.h and empty glext.h (which includes gl.h if necessary) is most likely the best way to proceed. These files could be dynamically created when switching implementations, to maintain consistency etc.. Or they could be static, and provided by opengl-update (similar to the /usr/lib/opengl/global profile).
My 0.02EUR: It seems to me that system common glext.h would be a bad idea because the OpenGL features available in the implementation are in part specified by the headers. So a system common glext.h would either contain the minimum common features which would give underutilisation of the features available or would contain too much leading to unresolved symbols. (Though I could be wrong on this.) Also I think a system common glext.h would be difficult to generate as the generating script would need to understand at least C preprocessor which is non-trivial. Also, people don't spend the whole time switching between OpenGL implementations: they choose one and stick with it. So from that POV, gtkglext should be compiled against the current GL implementation and then if people want to be able to swap between them they can make binpkgs for each OpenGL implementation and use those. Of course, the nvidia OpenGL headers will from time to time break gtkglext. So, we should at the beginning of src_compile check if the nvidia glext.h is incompatible with the gtkglext glext.h when both are included by gtkglext gdkglglext.h and if so error out with a comprehensible error message, sth along the lines of: > The OpenGL headers from your current OpenGL implementation are incompatible > with GtkGLExt. This is probably a bug in your current OpenGL implementation, > as the headers in GtkGLExt are derived from the SGI-provided OpenGL 1.2.1 > sample implementation. > Please check to see if there is a fix for your current OpenGL implementation > and, if so, emerge that then continue with the current emerge. > Otherwise, you may wish to switch OpenGL implementation for the duration of > this emerge; but note that you may have problems with programs that use > OpenGL, even possibly crashing your current X session. Also, you may need to > switch OpenGL implementation to emerge packages that use GtkGLExt. > Your current OpenGL implementation (opengl-update --get-implementation) is: > $(opengl-update --get-implementation) > You can switch OpenGL implementation with: > $ opengl-update xorg-x11 If you think this is a good idea I can write the test; it should be quite easy.
This might be interesting reading: http://oss.sgi.com/projects/ogl-sample/ABI/ In particular: 4.7. Vendor-specific shortcuts, such as macros for higher performance GL entry points, are intrinsically unportable. These should not be present in the required header files, but instead in a vendor-specific header file that requires explicit effort to access, such as defining a vendor-specific preprocessor symbol. Likewise vendors who are not willing to include their extensions in glext.h must isolate those extensions in vendor-specific headers. ... Instead, we require a single header file defining all OpenGL extensions be supplied from a central point and updated on a continuing basis as new extensions are added to the OpenGL extension registry (which is similarly centrally maintained). The central point is SGI's OpenGL Sample Implementation website at http://oss.sgi.com/projects/ogl-sample/ABI.
> It seems to me that system common glext.h would be a bad idea because the OpenGL > features available in the implementation are in part specified by the headers. > So a system common glext.h would either contain the minimum common features > which would give underutilisation of the features available or would contain > too much leading to unresolved symbols. (Though I could be wrong on this.) you are wrong. glext.h is standardized by the ARB. applications are expected to check both at compile time for the various constants to be defined, and at run time for the features they need. apps that don't are broken. iow, if i build against glext.h for OpenGL 1.5 and run against an OpenGL 1.2 system, and the app breaks, then that is a bug in the application. regarding the initial bug, gtkglext ought to be checking for a sufficient glext.h at configure time and only using its bundled one if the system one is too old. i wouldn't try to work around this in opengl-update.
OK, that makes a lot more sense. Thanks for pointing me to that resource. So... the implementation provided glext.h is not needed, in fact the standard glext.h (e.g. that provided by opengl-config) is sufficient? re comment 10, I've tried writing a parser for the various glext.h headers, you have to make quite a lot of assumptions about the way the file is structured to get anywhere with it. I'm willing to keep hacking at it but I do think that trying to merge implementation provided glext.h headers would be rather tricky and fragile; it would be better just to use the SGI glext.h and keep it up to date. (Perhaps glext.h, glxext.h and wglext.h could be provided in a separate package, say media-libs/opengl-headers?) Reading the SGI docs, it does seem that <the latest SGI sample glext.h> will always work in place of any implementation provided glext.h. So if we stick to the SGI glext.h everything should work fine and messing around switching OpenGL implementation becomes unnecessary. We can still keep the implementation provided glext.h around just not in the normal include paths; it can then be used by any applications which want non-portable speedups but they have to cope with any incompatibilities. Or even, make glext.h sth like: #ifdef GL_GLEXT_USE_NVIDIA_HEADERS #include "/path/to/nvidia/glext.h" #else #include "/path/to/standard/glext.h" #endif /* GL_GLEXT_USE_NVIDIA_HEADERS */ Now, this *could* be generated by opengl-update very easily. Another bonus is that when using the SGI glext.h, any errors with gtkglext are automatically a bug in gtkglext.
Please try opengl-update-2.2.0
Yep, seems fine.
Closing, thanks for testing.
