PDA

View Full Version : OpenGL Compile Errors



nukem
08-21-2003, 01:11 AM
I just got a new laptop(IBM Thinkpad T40 1.5ghz centrino 512 DDR ATI Radeon 7500 32Meg CD-RW/DVD) when I went to go compile my current project that has been compiling fine on my desktop(p-4 1.4ghz 512RDRAM nvidia geforce 2 mx 32meg(nvidia drivers) CD-RW/DVD) I get these two errors

NuclearBSP.cpp: In member function `void NuclearBSP::Q3::RenderFace(int)':
NuclearBSP.cpp:101: `glActiveTextureARB' undeclared (first use this function)
NuclearBSP.cpp:101: (Each undeclared identifier is reported only once for each
function it appears in.)
NuclearBSP.cpp: In member function `void NuclearBSP::Q3::Render(Vect3&)':
NuclearBSP.cpp:119: `glClientActiveTextureARB' undeclared (first use this
function)

Both computers run Redhat 9.0. My laptop uses DRI, while my Desktop uses the nvidia drivers. My desktop OpenGL version is 1.4 while my laptop version is 1.2, could this be the problem? I doublt it is, im pretty sure those functions have been in since at least verion 1.1. If it is does anyone know the rpm way to upgrade OpenGL/DRI. Does anyone know how to fix these errors?

Thanks
nuke

jide
08-21-2003, 02:21 AM
Originally posted by nukem:
I just got a new laptop(IBM Thinkpad T40 1.5ghz centrino 512 DDR ATI Radeon 7500 32Meg CD-RW/DVD) when I went to go compile my current project that has been compiling fine on my desktop(p-4 1.4ghz 512RDRAM nvidia geforce 2 mx 32meg(nvidia drivers) CD-RW/DVD) I get these two errors

NuclearBSP.cpp: In member function `void NuclearBSP::Q3::RenderFace(int)':
NuclearBSP.cpp:101: `glActiveTextureARB' undeclared (first use this function)
NuclearBSP.cpp:101: (Each undeclared identifier is reported only once for each
function it appears in.)
NuclearBSP.cpp: In member function `void NuclearBSP::Q3::Render(Vect3&)':
NuclearBSP.cpp:119: `glClientActiveTextureARB' undeclared (first use this
function)



Well, this generally happens when the compiler can't find the definition of your funcs. So, take a look if your gl.h on your laptop defines them. or you may have more than one gl.h include.



Both computers run Redhat 9.0. My laptop uses DRI, while my Desktop uses the nvidia drivers. My desktop OpenGL version is 1.4 while my laptop version is 1.2, could this be the problem? I doublt it is, im pretty sure those functions have been in since at least verion 1.1.


As far as I remember, multitexturing is known in gl 1.2; so as you say, this is surely not the problem.




If it is does anyone know the rpm way to upgrade OpenGL/DRI. Does anyone know how to fix these errors?

Thanks
nuke

I may tell you something wrong: use Mesa ?!
and something horrible but just to ensure: do you declare gl.h in your source file cpp or header ?

hope this helped (a bit)

nukem
08-21-2003, 01:56 PM
I know what the errors mean I was just trying to show them to everyone so they can see my problem. I have looked in /usr/include/GL/gl.h(thats the only gl.h on my laptop) to see if these functions are in there, they both are. Yes the hole mesa thing that was a big mistake I made in the fourms awhile back, sorry. I have tryed including gl.h directly in NuclearBSP.cpp and I still get the same problem, usally its decleared in an include file included by NuclearBSP.h.

[This message has been edited by nukem (edited 08-21-2003).]

jide
08-22-2003, 02:54 AM
Originally posted by nukem:
I know what the errors mean I was just trying to show them to everyone so they can see my problem. I have looked in /usr/include/GL/gl.h(thats the only gl.h on my laptop) to see if these functions are in there, they both are. Yes the hole mesa thing that was a big mistake I made in the fourms awhile back, sorry. I have tryed including gl.h directly in NuclearBSP.cpp and I still get the same problem, usally its decleared in an include file included by NuclearBSP.h.

[This message has been edited by nukem (edited 08-21-2003).]

So take a look at the gl specs somewhere here, to know if this is effectively gl 1.2 or above.

I think I've found your problem, maybe easy, or maybe a fool idea, let me know ! as I don't remember the way this is done:

These are extensions funcs. Do you provide glXGetProcAddressARB() to find them out ?

smthg like:

GLXGETPROCADDRESSARB my_gl_active_texture_arb= glXGetProcAddressARB( "glActiveTextureARB");

But this is normally the linker task, not the compiler. And it works on your desktop...

do you include gl.h in a namespace ?

however tell the much you can.

hope this helped (a bit)

nukem
08-24-2003, 12:35 PM
I dont think I understand. I dont use glXGetProcAddressARB but I doubt that will do anything since the error is glActiveTextureARB undeclared. How would I include gl.h in a namespace? I tryed using namespace gl; but that dosnt work.

I just ran a precompiled version from my desktop on my laptop and it ran. So I dont think its like my laptop version of OGL dosnt support it.

[This message has been edited by nukem (edited 08-24-2003).]

luxo
08-25-2003, 06:14 AM
I had a similar issue a while back with shader programming functions. You may need to define some constant while compliling to get those functions. Check to see if there are any #ifdefs around the function declarations in gl.h and if so, use -DSOME_CONSTANT when compiling.

Hope that helps.

nukem
08-25-2003, 11:35 AM
Thanks luxo its compiling now!!! For some reason this function is declared in gl.h and glext.h if GL_GLEXT_LEGACY is not definded in gl.h then it goes to glext.h if GL_GLEXT_PROTOTYPES is not defined in glext.h you dont have multitexturing. I defined GL_GLEXT_LEGACY so im using the functions from gl.h, but both work. I also didnt add -DSOME_CONSTANT to my Makefile and it still compiles. Unless you see a reason to put it in I see no reason in putting it in.

Thanks for all your help
nuke

Brian Paul
08-25-2003, 01:24 PM
The solution is to define GL_GLEXT_PROTOTYPES before including GL/gl.h:

#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h> // also includes glext.h


In general, if you want to get function prototypes for extension functions, define GL_GLEXT_PROTOTYPES first.

But, if you want to really be portable, you should use glXGetProcAddress to get a function pointer at runtime, rather than using direct calls to GL functions which may or may not be present in an arbitrary OpenGL implementation.

-Brian

nukem
08-25-2003, 04:37 PM
So are you saying I should use GL_GLEXT_PROTOTYPES instead of GL_GLEXT_LEGACY? What the diffrenace? While im hoping to make my project portable right now im more conserned on finishing it.

jide
08-26-2003, 04:31 AM
Originally posted by nukem:
So are you saying I should use GL_GLEXT_PROTOTYPES instead of GL_GLEXT_LEGACY? What the diffrenace? While im hoping to make my project portable right now im more conserned on finishing it.

No, that is not what he (and I) said.
You should get the gl (ARB;NV,ATI,EXT,SGI,IBM,S3) ext funcs during the run-time of your program.
You're not advise to use defines like that, they are system definitions.
I don't remember correctly the full way to link to these funcs, but this is like this:

1. Get the definition of your proc (glActiveTextureARB and the other)
2. declare the func as you declare a pointer to a function in C with not the same name (just my advice)
3. link the func to your func pointer with glXGetProcAddress( "gl_ext_func_name");
4. If your pointer is not null, you're OK to use it generally.

So the principle for ext,ARB... funcs is the following:
never use them as they are defined in gl. or glext.h (which you'll never need to use), but use function pointers instead.

If what I said is not understandable for you (I can understand that), you will find easily how to do so in this site, or in Nehe tuts or anywhere on the net.

hope this helps

jide

jide
08-26-2003, 04:34 AM
Originally posted by nukem:
I dont think I understand. I dont use glXGetProcAddressARB but I doubt that will do anything since the error is glActiveTextureARB undeclared. How would I include gl.h in a namespace? I tryed using namespace gl; but that dosnt work.

Well, in fact C hasn't got namespace !



I just ran a precompiled version from my desktop on my laptop and it ran. So I dont think its like my laptop version of OGL dosnt support it.

[This message has been edited by nukem (edited 08-24-2003).]

luxo
08-26-2003, 05:48 AM
nukem, what they are saying is that, if you use function pointers and simply check to see if the function pointer obtained by glXGetProcAddress() (or wglGetProcAddress() on Windows, aglGetProcAddress() on Mac) is NULL or not then you will be able to compile on almost any platform. How you handle the case where the multitexturing functions aren't defined in a particular OpenGL implementation is up to you.

However, if you #define or -D a constant, it may compile on some platforms but not on others where that constant isn't used.

So, if you want to be portable, use the GetProcAddress functions rather than defining constant(s).

nukem
08-26-2003, 08:21 AM
Ok thank I get it. Ill implement getProcAddress today. luxo seems to be telling me though glXGetProcAddress is diffrent on every OS, isnt there one that works on every OS?

jide
08-27-2003, 03:06 PM
In fact, no.

you'll use wglGetProcAddress under W32, and surely aglGetProcAddress under Mac.
But fortunately, they got the same structure declaration, so you could use here #defines to know which one to use.
I think this is due mainly that OpenGL is not OS dependant, and libs are written differently under each OS.

hope this helps

nukem
08-27-2003, 03:09 PM
Arent the libs written diffrently for each video card? I know there are some thing diffrent for each gui system. I would think that glXGetProcAddress works on all OS's that use X.

luxo
08-27-2003, 07:29 PM
If you write your OpenGL code carefully, then you should be able to compile and run it on any OS (that's not to say that it will behave exactly the same on every OS... just that it will compile and run).

However, with respect to the xxxGetProcAddress() function, since it is part of the platform-specific OpenGL extensions (GLX on X Windows, WGL on MS Windows, and AGL on Mac) then you need to use the platform specific versions of it if you want to be cross-platform (glXGetProcAddress, wglGetProcAddress, and aglGetProcAddress).

Hope that clears things up.

nukem
08-28-2003, 12:39 AM
Ya it does thanks. They should really make all the OGL functions the same on every OS, even if they are OS specific.

nukem
08-28-2003, 12:57 AM
I was looking up docs for glXGetProcAddress and I couldnt find any on this site or google. Does anyone know were I can find some good docs and/or examples?

I also looked in GL/glx.h and saw this



/* GLX 1.4 and later */
extern void (*glXGetProcAddress(const GLubyte *procname))(void);


Does that mean this will only work with OpenGL 1.4 and later?

jide
09-03-2003, 01:21 PM
Originally posted by nukem:
I was looking up docs for glXGetProcAddress and I couldnt find any on this site or google. Does anyone know were I can find some good docs and/or examples?


Well this is surely what you want. I could find it :-)
http://www.opengl.org/developers/code/fe...s+glx#first_hit (http://www.opengl.org/developers/code/features/OGLextensions/OGLextensions.html?extensions+glx#first_hit)

This is how the things work for all extensions.



I also looked in GL/glx.h and saw this



/* GLX 1.4 and later */
extern void (*glXGetProcAddress(const GLubyte *procname))(void);


Does that mean this will only work with OpenGL 1.4 and later?

Well, no.
glx, agl, wgl don't evoluate at the same speed and at the same 'version' that Opengl. This is surely disconcerting but that's the way it goes.

GetProcAddres will work for gl 1.2 and even 1.1 (but I'm not sure).

Hope this helps

Jide

nukem
09-03-2003, 01:50 PM
heh thanks I just searched for glXGetProcAddress.

m2
09-07-2003, 08:10 AM
Originally posted by nukem:
I was looking up docs for glXGetProcAddress and I couldnt find any on this site or google. Does anyone know were I can find some good docs and/or examples?

May I plug GLEW here? http://glew.sf.net/


I also looked in GL/glx.h and saw this



/* GLX 1.4 and later */
extern void (*glXGetProcAddress(const GLubyte *procname))(void);


Does that mean this will only work with OpenGL 1.4 and later?

GLEW solves that, too. And your original problem. And the problem you posted about later. :-)