What is the correct way to include GLEW in a Mac OS X .framework?

Question

Probably a very simple problem, but it's had me stumped.

I've got an SDL/OpenGL/GLEW based static library that compiles (gcc/g++) and links fine on Windows. On OS X, the same codebase fails to compile claiming that it can't find the declaration of GL_NUM_EXTENSIONS and::glGetStringi() - which is since I've thrown GLEW in the mix (with only SDL and OpenGL, it builds fine on OS X too).

// globals.h
#include <glew.h>
#include <SDL/SDL.h>

// graphics.h
#include "globals.h"

bool HasGLExtension(const char* pName);

// graphics.cpp
#include <string>
#include "graphics.cpp"

bool HasGLExtension(const char* pName)
{
  GLint numExtensions;
  ::glGetIntegerv(GL_NUM_EXTENSIONS, &numExtensions); // error
  for (int i = 0; i < numExtensions; ++i)
  {
    if (strcmp(pName, (char*)::glGetStringi(GL_EXTENSIONS, i)) == 0) // error
    {
      return true;
    }
  }
  return false;
}

• the dependent libraries, built as frameworks, are situated at /Library/Frameworks.
• the -DGLEW_STATIC -DSDL_NO_GLEXT compile flags are used (as needed on Windows - the problem persists even if I remove them).
• even auto-completion confirms that the location of glew.h exists (then again, of course, that's not the error I'm getting -- it's the symbols).
• including SDL/SDL_opengl.h will just result in conflicting declarations.
• the problematic definitions are present in glew.h

What's the obvious that I'm missing?

Answer 1

Don't do it. For something that 1, is easy to set up and 2, works out of the box and 3, has little to no encumbrance in its licensing, use glLoadGen .