#429 does not build against mesa-10.x

[hasufell]

g++ -Wall -pipe -fno-exceptions -fno-rtti -fstrict-aliasing -g -D_DEBUG -I../../include -Izlib -Ijpeglib -Ilibpng -I/usr/X11R6/include -DIRRLICHT_EXPORTS=1 -c -o COpenGLDriver.o COpenGLDriver.cpp
In file included from COpenGLDriver.h:25:0,
from COpenGLDriver.cpp:5:
COpenGLExtensionHandler.h:1236:3: error: ‘PFNGLBLENDEQUATIONPROC’ does not name a type
PFNGLBLENDEQUATIONPROC pGlBlendEquation;
^
COpenGLExtensionHandler.h: In member function ‘void irr::video::COpenGLExtensionHandler::extGlBlendEquation(GLenum)’:
COpenGLExtensionHandler.h:2566:6: error: ‘pGlBlendEquation’ was not declared in this scope
if (pGlBlendEquation)
^
make: *** [COpenGLDriver.o] Error 1

[hasufell]

https://bugs.gentoo.org/show_bug.cgi?id=496356

[Christian Stehno]

The type looks to be defined in OpenGL 1.2, which means it should be there for all backward compatible OpenGL contexts!? Please confirm that this type has been removed, as it wasn't even deprecated before.

[Anonymous]

same problem here, any progress?

[Christian Stehno]

Well, what I meant with my comment is: The error complains about a missing type. This type should be defined in every glext.h (or even gl.h) since version 1.2, which is required for Irrlicht to work. So the mesa header seems wrong.

[Anonymous]

i can find the defination in glext.h header

file glext.h line 413:
typedef void (APIENTRYP PFNGLBLENDEQUATIONPROC) (GLenum mode);

but irrlicht cant

[Christian Stehno]

Is it the correct header that you checked? The Irrlicht glext.h does have it, but most distros tend to use their own system glext.h, here probably the one provided by mesa10. Once you're sure which header it tsakes, please upload it here (or tell me it's the Irrlicht one).

[Anonymous]

deleting the /source/Irrlicht/glex.h and change "glex.h" to < GL/glex.h > in COpenGLSLMaterialRenderer.h fix it, now I can compile and all examples run ok

--- edited
all references to glex.h in all files that need it, must be changed to use the < GL/glext.h >

I cant understand why the local version conflicts with the system version
but forcing the system one work
sorry for the bad english

[hasufell]

That doesn't work for me, still the same build failure.

[Christian Stehno]

Maybe you have an old glext.h somewhere else. With the Mesa glext.h it should probably work, with the newer Irrlicht one as well.

[hasufell]

I don't have an old glext.h anywhere. I don't install packages outside of the package manager.

[Christian Stehno]

I've checked this now with an Ubuntu 14.04 install, using Mesa 10.1.0 version. The bug was reproducible and it is now fixed, using the code from the repository. I cannot tell you what you should do as a work-around if you don't use the latest SVN version. After all, the source code was found to be bugged. You can, though, get a patch file from our repository server and add this to the set of patch files applied in the beginning of the make process. This would be a solution for the package maintainers if they want a solution before our next Irrlicht release.
This bug is for sure fixed and this ticket is closed, which is why you cannot respond to the discussion easily. In case you need some more help please use the forum thread on this topic.

[Christian Stehno]

Ok, digging a little further I found that our header (original version from Khronos, but from 2011) has a wrong version attributed for this typedef. The support in OGL ARB for glBlendEquation was for 1.4 only, before it was in ARB_imaging. The header we use for Irrlicht 1.8.x has this errorneously put into version OGL 1.2.
Since Mesa supports 1.2 already, it brings all typedefs in gl.h - but of course not the BlendEquation one, as that is not for 1.2. However, up to commit a36f7e651e947ff14dbbd242b1d9ab160442c532 the gl.h contained those typedefs anyway - probably due to some legacy problems. And since Mesa does not support OGL 1.4 right now, there's no way to include this typedef with the current setup.
You should for now replace the glext.h with the system one's as that one is newer anyway. The development version has a newer glext.h already. Not sure whether 1.8 branch will get an update anytime soon.

[Christian Stehno]

I've updated glext.h with the version we use in trunk. Compiles here and should also solve this problem.