Since upgrading to 1.0-6106, OpenGL programs using GL_MAX and glBlendEquation() fail to build. This is because they have been moved by nvidia from gl.h to glext.h. This last file comes with the nvidia package but is not installed (see Gentoo bugs #43176 and #37517). I appreciate that, in those bug fixes, the decision was taken to abandon nvidia's glext.h and stick with XFree's, but nvidia have made this path untenable. Can you please look again at opengl-update and the decision to install nvidia's glext.h file? By the way, nvidia have made a real hash of things. Even after manually installing the missing file, to get to actually use glBlendEquation() again, I had to add the following code to my program (after the pre-existing #include of GL/glu.h) ... #ifndef GL_GLEXT_PROTOTYPES # define GL_GLEXT_PROTOTYPES # define __DEFINED_GL_GLEXT_PROTOTYPES #endif #ifndef GLAPI # ifdef _WIN32 # define GLAPI __stdcall # else # define GLAPI # endif # define __DEFINED_GLAPI #endif #include <GL/glext.h> #ifdef __DEFINED_GLAPI # undef GLAPI # undef __DEFINED_GLAPI #endif #ifdef __DEFINED_GL_GLEXT_PROTOTYPES # undef GL_GLEXT_PROTOTYPES # undef __DEFINED_GL_GLEXT_PROTOTYPES #endif Reproducible: Always Steps to Reproduce: 1. 2. 3.
This is being handled by bug #54984 .. but can be used to track the _badness_ of glext.h in the new version. In regards to the bad defines in gl.h / glext.h that will be fixed by using SGIs recommended glext.h (and patching nvidias gl.h to have the include for GL/glext.h) ..
Just commited fixes for TLS and glext.h to cvs. Please update your portage tree and remerge nvidia-glx (which should ask you to update to opengl-update-1.8 if it doesnt you havent got the new version yet). The changes should fix the error. Please report back.
After updating to opengl-update 1.8 and reemerging nvidia-glx I get the following error from opengl-update: # opengl-update nvidia * Switching to nvidia OpenGL interface... rm: cannot remove `/usr/lib/tls': Is a directory [ ok ]
That directory should have been removed when you unmerged nvidia-glx. Remove it manually and then remerge nvidia-glx.
It's broken. I did an emerge -uD world -p and had to put opengl-update in my /etc/portage/package.keywords file. I redid the emerge and now get the message about moving gltext.h. I moved it - still get asked to move it. I check - it is moved, named correctly, still get asked to move it. The ebuild doesn't believe it's there.
resync your tree. Fixed in cvs about 9 - 10 hours ago.
*** Bug 57401 has been marked as a duplicate of this bug. ***
still get TLS error when launching cedega: err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: libnvidia-tls.so.1: cannot handle TLS data Could not load graphics driver 'x11drv' runing latest xorg, latest glx and latest opengl-update. the error doesn't show running "opengl-update xorg-x11" instead of "nvidia".
Have you re-merged cedega? Can you attach a strace of cedaga in plain text format aswell if possible...
Seemed to work fine for me (after putting opengl-update /etc/portage/package.keywords). Installed on two machines now.
Sigh! This fix DOES NOT WORK! Now, I can not get our software to compile at all. The software used glBlendEquation(). This is declared in glext.h. However, it is "protected" by the following code ... #ifndef GL_VERSION_1_2 #define GL_VERSION_1_2 1 #ifdef GL_GLEXT_PROTOTYPES ... GLAPI void APIENTRY glBlendEquation (GLenum); So, I can ONLY see the declaration of glBlendEquation() iff GL_VERSION_1_2 is NOT defined. Unfortunately, what do I see inside gl.h ... /* Patching for some better defines in the global system */ #define GL_VERSION_1_2 #define GL_VERSION_1_3 #define GL_VERSION_1_4 #include <GL/glext.h> Aaaaaaaaaaaaaaaarrrrrrrrrggggggggggghhhhhhhhhh! Sorry for the frustration, but I am NOT an OpenGL programmer, I just want to continue using Gentoo on my machine and be able to compile our products under it ...
Had to give altogether trying to #include glext.h for the moment. For the benefit of others, my example workaround (above) has changed to: #ifdef __cplusplus extern "C" { #endif #ifndef GLAPI # ifdef _WIN32 # define GLAPI __stdcall # else # define GLAPI # endif # define __DEFINED_GLAPI #endif GLAPI void APIENTRY glBlendEquation (GLenum); #ifdef __DEFINED_GLAPI # undef GLAPI # undef __DEFINED_GLAPI #endif #ifdef __cplusplus } #endif Unless anyone can suggest a better way of doing it?
This really is a blame nvidia thing, these definitions and the include /* Patching for some better defines in the global system */ #define GL_VERSION_1_2 #define GL_VERSION_1_3 #define GL_VERSION_1_4 #include <GL/glext.h> Are meant to say that gl.h contains all the headers for GL_VERSION 1.2, 1.3, 1.4 which is what apparently it has, obviously this is not the case, so need more patches in gl.h to make it the case... Basically anything defined in those three versions should be defined in gl.h supposedley -- nvidia did it weird and put in only 1.1 support, but then defined some of the 1.2, 1.3, 1.4 headers. Attach patches if you can otherwise ill get to it soonish (just went back to uni so few days of being busy).
I'm happy with my latest bodge, Andrew. You're right, NVidia need a good slap across the face with a wet kipper! The video driver and libraries seem very stable, but the header files ... Thanks for trying to sort this out.
Graham, if you manually remove those GL_VERSION defines from /usr/include/GL/gl.h (all of them) do you get "previously defined symbol" errors???
Andrew - sorry for not getting back to you sooner - I've been away and not receiving these emails. I'm back in work tomorrow. I'll try out your suggestion and get back to you with the news. In the meantime, I've updated from xfree to xorg-x11. Hope this does not affect anything here ...
Andrew - applying the following: *** gl.h-orig 2004-07-28 12:38:59.694433528 +0100 --- gl.h 2004-07-28 12:59:06.784927880 +0100 *************** *** 67,75 **** typedef void GLvoid; /* Patching for some better defines in the global system */ - #define GL_VERSION_1_2 - #define GL_VERSION_1_3 - #define GL_VERSION_1_4 #include <GL/glext.h> /*************************************************************/ --- 67,72 ---- means that everything compiles IFF I surround my #include lines so ... #ifndef GL_GLEXT_PROTOTYPES # define GL_GLEXT_PROTOTYPES # define __DEFINED_GL_GLEXT_PROTOTYPES #endif #include <GL/gl.h> #ifdef __DEFINED_GL_GLEXT_PROTOTYPES # undef GL_GLEXT_PROTOTYPES # undef __DEFINED_GL_GLEXT_PROTOTYPES #endif which is MUCH better! I wish someone could explain why I have to do this #define of GL_GLEXT_PROTOTYPES and whether it is "the usual thing to do" or really is a hack!
*** Bug 60662 has been marked as a duplicate of this bug. ***
*** Bug 57712 has been marked as a duplicate of this bug. ***
Graham: See how you go with the version of nvidia-glx that I just added to cvs (it doesnt add the GL_VERSION defines to gl.h, instead it defined GL_GLEXT_PROTOTYPES) Basically nvidias gl.h is meant to provide OpenGL 1.1 support, beyond that is supposed to be an "extension" .. GL_GLEXT_PROTOTYPES includes "prototype" functions .. but in a distributable way they should be available hence why I have defined this across the board... I didnt revision bump or anything so make sure you re-merge in an hour or so...
OK have revised the patch, if you need functions in the GL_GLEXT_PROTOTYPES defined region you will need to define GL_GLEXT_PROTOTYPES in your code... This is how its meant to happen ... Marking as cantfix because its technically not how it used to work but is how its meant to be.
Andrew - sorry for delay. Finally got around to (re-)emerging the 6111 nvidia-glx package, undo-ing my hacks, adding "#define GL_GLEXT_PROTOTYPES" and rebuilding our stuff. All now builds fine, thanks. Good job.
Thanks
