   glGenFramebuffers null pointer in 3.2 context but works with 3.1
  Im pretty baffled by what is going on, when i request for a 3.2 context, glGenFramebuffers is a null pointer. If i request for a 3.1 or 3.0 context, there is no problem and everything runs fine. As far as im aware glGenFramebuffers was not depreciated in 3.2. Im using SFML v2 from the SVN snapshot and glew to load my extensions.sf::ContextSettings Settings;Settings.MajorVersion = 3;Settings.MinorVersion = 2;//Opengl 3.2canvas.Create(sf::VideoMode(WIDTH, HEIGHT, 32), "High Poly Viewer", sf::Style::Close, Settings);   GLenum err = glewInit();//Initialise Glew to handle extensionsif (GLEW_OK != err){std::cout<<"Error, could not init GLEW\n";}glGenFramebuffers(1, &FBOid);//Fails here, glGenFramebuffers is a null pointerJust for more info, this is the SFML source code which creates the actual context.  // Create the OpenGL context -- first try an OpenGL 3.0 context if it is requested    while (!myContext && (mySettings.MajorVersion >= 3))    {   PFNWGLCREATECONTEXTATTRIBSARBPROC wglCreateContextAttribsARB =reinterpret_cast<PFNWGLCREATECONTEXTATTRIBSARBPROC>(wglGetProcAddress("wglCreateContextAttribsARB"));   if (wglCreateContextAttribsARB)   {  int attributes[] =  { WGL_CONTEXT_MAJOR_VERSION_ARB, mySettings.MajorVersion, WGL_CONTEXT_MINOR_VERSION_ARB, mySettings.MinorVersion, 0, 0  };  myContext = wglCreateContextAttribsARB(myDeviceContext, sharedContext, attributes);   }   // If we couldn't create an OpenGL 3 context, adjust the settings   if (!myContext)   {  if (mySettings.MinorVersion > 0)  { // If the minor version is not 0, we decrease it and try again mySettings.MinorVersion--;  }  else  { // If the minor version is 0, we decrease the major version and stop with 3.x contexts mySettings.MajorVersion = 2;  }   }    }In all cases, Glew returns OK during init.Also, in the 3.2 case, GL_VERSION returns 3.20. Hardware is a nvidia G210 and using latest drivers.   
  You might have better luck with this on the SFML forum. Are you using the latest version of GLEW? I do believe it is not depreciated as well.   ;  As mentioned by me in other threads, most of current GUI libraries for OpenGL are still not enough to support OpenGL 3.2 core profile, include freeglut, SDL, QT. The next version of SDL and QT will provide full support.In your codes, the 3.2 context is created with the default profile: core. So I guess it has not been supported in SFML yet. You can try the compatibility profile.int attributes[] =  { WGL_CONTEXT_MAJOR_VERSION_ARB, mySettings.MajorVersion, WGL_CONTEXT_MINOR_VERSION_ARB, mySettings.MinorVersion, WGL_CONTEXT_PROFILE_MASK_ARB,WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB, 0, 0  };;  But i want to use the core profile to make sure im not using any depreceated features.Anyway after wasting an entire day on it, i found the problem. It's not SFML that is causing the problem. The problem was that there is a bug in GLEW for Core profiles. GLEW makes use of glGetString(GL_EXTENSIONS) to retrieve extensions, which is depreceated since 3.0. Therefore GLEW fails to get any extensions in a core gl3 context.As to why it worked with 3.1 and 3.0, the gl specs state that wglCreateContextAttribsARB will return a compatibility profile by default for 3.0 and 3.1. Since SFML does not specify a core/compatibility profile, it always returns a compatibility profile pre 3.2 which allowed glGetString(GL_EXTENSIONS) to work in GLEW. The bug tracker in GLEW has this issue, but there is noone willing to fix the issue in the codebase yet. Ive made a simple fix for it in glew.c assuming the minimal context will be 3.0 or higher so that i can bypass the old GLEW extension code entirely.Hopefully this helps others with this problem.;  Your comment is useful for my problems of using core profile in freeglut. I will give a try. Thanks!   ;  Finally, I find the cause of my problem of missing some functions of core profile using GLEW 1.5.4. =========================="Experimental DriversGLEW obtains information on the supported extensions from the graphics driver. Experimental or pre-release drivers, however, might not report every available extension through the standard mechanism, in which case GLEW will report it unsupported. To circumvent this situation, the glewExperimental global switch can be turned on by setting it to GL_TRUE before calling glewInit(), which ensures that all extensions with valid entry points will be exposed. "============================I add the "glewExperimental= GL_TRUE;" before "glewInit();". Everything is OK.   