The headers are working fine, it's just that the functions are in the global namespace but you put them in the cf namespace, so I get undefined references to, say cf::glMultiTexCoord2dARB (because its just glMultiTexCoord2dARB in the global namespace) . I think I'll need to do something like this in OpenGLEx.hpp, but it would not be ideal:



By the way, pretty much all of the code in OpenGLEx.cpp is not needed on OS X.

Yes, I understood that in the previous post. The situation under Linux is similar: Many functions such as ::glMultiTexCoord2dARB() are readily declared in the header files - but others (those from newer or rarely used extensions) are not.
Contrary to Mac OS X, under Linux it is difficult to know in advance which of these functions are in the header, and which are not - it just depends on the version of the header file, and thus on the details of the distribution.

That means that under Windows, none of the functions are in the headers, under Linux some, and under Mac most (or even all).
Good news is that the system specific xyzGetProcAddress() can be used to query them all - both those already declared in the header files, as well as those that aren't.

This obviously looks like unnecessary work for the methods that are already there, but has several advantages:

• The code is the same everywhere - Windows, Linux, and (possibly) Mac, no difficult special cases like the inline functions above.
• Note that if we were to use extensions that are not pre-declared in the system header files, we'd be back to the xyzGetProcAddress() function anyways - depending on the version of the system header.
• At runtime, if you run a binary that was compiled on e.g. OS X 10.6 whose system libraries support a certain newer extension, and have it run on e.g. OS X 10.4, whose system libraries do not yet support the newer extension, because it was only known to OS X 10.6, the Renderer dynamic library would not load due to unresolved symbols.

It's ok (even if not the most beautiful code in the world) if you proceed with the inline functions as you suggested above, but I'd be in favor of trying the OS X equivalent of the xyzGetProcAddress() function first as explained in my previous post - it's just more universal.