You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
This should be the old nvidia include bug, it's not a general problem with the code. You have to adapt the include path such that the nvidia OpenGL includes are chosen. Otherwise there's a mismatch between includes and library.
hybrid wrote:This should be the old nvidia include bug, it's not a general problem with the code. You have to adapt the include path such that the nvidia OpenGL includes are chosen. Otherwise there's a mismatch between includes and library.
i verified this against X.org/Mesa-6.8.2-1.EL.13.20 and
nVidia-1.0-7676 headers and my fix holds true, because
Mesa defines either:
So for me (ATI headers) its working with the original code already. And your code relies on all these things to be defines, which might not always hold. But searching for an always working scheme has been a struggle for quite some time now.
hybrid wrote:So for me (ATI headers) its working with the original code already. And your code relies on all these things to be defines, which might not always hold. But searching for an always working scheme has been a struggle for quite some time now.
what may be wrong is the assumption that 'glXGetProcAddressARB' is
funtionally equivalent to 'glXGetProcAddress' under both Mesa and nVidia.
i also verified this agains ATI (fglrx_6_8_0-8.19.10-1.i386.rpm) headers and
my fix still does no break since ATI does not define 'GLX_ARB_get_proc_address'
and links ok with 'glXGetProcAddress'.
I see that I mixed up with the different symbols and functions. So GLX_ARB_get_proc_address is always a define? Is it an official OpenGL define, or just Mesa?
But why not using it's value directly? Just define the Irrlicht define to GLX_ARB_get_proc_address, which should be correct. If it does not exist use the original code as fallback. Since all current solutions are hacks it's probably best to be as fail safe as possible.
Ah, that's an interesting discussion, and I'm really keen on getting this problem solved. I think I'll try out some versions, upload them and let lots of people try it out, that's the only way you can really be sure
hybrid wrote:I see that I mixed up with the different symbols and functions. So GLX_ARB_get_proc_address is always a define? Is it an official OpenGL define, or just Mesa?
But why not using it's value directly? Just define the Irrlicht define to GLX_ARB_get_proc_address, which should be correct. If it does not exist use the original code as fallback. Since all current solutions are hacks it's probably best to be as fail safe as possible.
as i see it, GLX_ARB_get_proc_address is defined to '1' in the opengl headers if the corresponding library supports only the ARB version of the function-call.
You'll have to be in directory source/Irrlicht for this to work, though. Check the filename in the first line of the patch. This is the file to be patched. But using the -p1 tells the patch tool to remove the first directory entry of the file name- you could instead use -p0 and issue that call from source/ directory.
Again some problem with header/library mismatch. Your OpenGL headers used during compilation do not match with the libraries loaded at start. If you're using NVidia drivers you should search for the correct includes in some nvidia speicif directory (I think under /usr/share/doc/packages/). And be sure to use the same libraries during linking and execution as different APIs will break execution.
I've had the exact same problem everytime I get a new Irrlicht version. I'm also using the nVidia drivers for OpenGL. I patch my irrlicht version by hand everytime to make it work... :\ I'm using Xandros 3.0 Deluxe, which is based on Debian.
I understand why I would need to use nVidia specific headers for nVidia specific libraries, but I'm not specifying nVidia specific libraries when I build, just -lGL. It really is a mis-configured system, IMO. If the default GL libraries are nVidia, the default GL includes should be nVidia too.
LOL I never figured out the header file thing, but I didn't try very hard.