Suppose I have code

TestExample.cpp

#include "GL/glew.h"
int main(){
  glewInit();
  GLuint id = 0;
  glGenTextures(1, &id);

  return 0;
}

g++ TestExample.cpp -lGLEW returns a compile error

/usr/bin/ld: /tmp/ccwGckkm.o: undefined reference to symbol 'glGenTextures'
//usr/lib/nvidia-352/libGL.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

I need to compile it with g++ Example.cpp -lGLEW -lGL for it to pass compilation.

The confusing part for me is if I move the glew portion into a class and compile it as a library, no linking against libGL is needed and it compiles fine and runs fine. For example,

TestExample.cpp

#include "Test.h"
int main(){
  Test test;
  test.Print();
  return 0;
}

Test.h

class Test{
 public:
  Test();
  ~Test();

  void Print();
};

Test.cpp

#include "Test.h"
#include "GL/glew.h"
#include <iostream>

Test::Test(){}
Test::~Test(){}

void Test::Print(){
  glewInit();

  GLuint id = 0;
  glGenTextures(1, &id);

  std::cout << "test!" << std::endl;
}

g++ -fPIC -I. -o Test.o -c Test.cpp
g++ -shared -Wl,-soname,libTest.so -o libTest.so Test.o -lGLEW
g++ TestExample.cpp -L. -lTest
./a.out shows test!

Please advice, thanks!

Here is the output from the CMake configure:

The C compiler identification is MSVC 18.0.31101.0
The CXX compiler identification is MSVC 18.0.31101.0
Check for working C compiler using: Visual Studio 12 2013 Win64
Check for working C compiler using: Visual Studio 12 2013 Win64 -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler using: Visual Studio 12 2013 Win64
Check for working CXX compiler using: Visual Studio 12 2013 Win64 -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindPkgConfig.cmake:381 (message):
pkg-config tool not found
Call Stack (most recent call first):
C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/FindPkgConfig.cmake:395 (_pkg_check_modules_internal)
CMakeLists.txt:26 (pkg_check_modules)

Configuring incomplete, errors occurred!
See also "C:/game_dev/3rd/glew-1.12.0/cmake-build/CMakeFiles/CMakeOutput.log".

Using in a Mac project where clang modules are enabled causes many errors starting with:

/usr/local/include/GL/glew.h:16426:17: error: declaration of 'PFNGLCOPYTEXSUBIMAGE3DPROC' must be imported from module 'OpenGL.GL3' before it is required

Here's what's going on. When GLEW loads glu.h the entire OpenGL.framework PCH is brought in ignoring the #define _gl_h from glew.h meant to prevent this. Things like GL_VERSION_1_2 become defined. So the GLEW typedefs and defines get skipped.

Can the loading of glu be done at the very end? I built a Swift package to wrap GLEW and created a shim that has that effect. Seems to work. Couldn't figure out any other way because there's currently no option to turn off clang modules in Swift (and there may never be).

https://github.com/AE9RB/SwiftCGLEW/blob/master/shim.h

Note that this package is for the newly open source Swift. It enables OpenGL on all platforms. If you want to test SwiftGLEW you'll need a GL context, so here's a binding to GLFW3: https://github.com/AE9RB/SwiftCGLFW3

Hi all,

i did a simple git clone to get the sources and typed "make" like the documentation tells me but i only get something like: make: *** No Rule found to build „src/glew.c“,
needed to build „tmp/linux/default/shared/glew.o“. Finish.

.. what am i doing wrong ??

There are no glew.c/glew.h files. This presents a problem trying to build with Visual Studio.

I ran the glewinfo.exe and it reported support for OpenGL version 4.5.0. Here is a snippet of the glewinfo.txt. I've attached the whole text file in case needed.

GLEW version 1.13.0
Reporting capabilities of pixelformat 1
Running on a GeForce GTX 970/PCIe/SSE2 from NVIDIA Corporation
OpenGL version 4.5.0 NVIDIA 368.81 is supported
glewinfo.txt

This is somewhat confusing because I would expect version detection to be based on what the hardware officially states in its specifications. Here is a link to my video card specs. I pulled out my product box to be sure this is the correct card. Note that it says "OpenGL 4.4 Support".
http://www.evga.com/Products/Specs/GPU.aspx?pn=d8328514-f9bc-44aa-ae85-d50c9f433297

context_flush_control is being detected properly, but is unusable without the required definitions used to build the attribute list, and GLEW is prevents us from including [glx|wgl]ext.h because of, for example, #define __glxext_h_ in glxew.h

glxew.h and wglew.h are missing the following CONTEXT_RELEASE_BEHAVIOR definitions for the context flush control extension:

[GLX|WGL]_CONTEXT_RELEASE_BEHAVIOR_ARB
[GLX|WGL]_CONTEXT_RELEASE_BEHAVIOR_NONE
[GLX|WGL]_CONTEXT_RELEASE_BEHAVIOR_FLUSH_ARB

https://www.opengl.org/registry/specs/KHR/context_flush_control.txt

We need the following defines in glxew.h:

/* --------------------- GLX_ARB_context_flush_control --------------------- */

#ifndef GLX_ARB_context_flush_control
#define GLX_ARB_context_flush_control 1

#define GLX_CONTEXT_RELEASE_BEHAVIOR_ARB  0x2097
#define GLX_CONTEXT_RELEASE_BEHAVIOR_NONE_ARB 0
#define GLX_CONTEXT_RELEASE_BEHAVIOR_FLUSH_ARB 0x2098

#define GLXEW_ARB_context_flush_control GLXEW_GET_VAR(__GLXEW_ARB_context_flush_control)

#endif /* GLX_ARB_context_flush_control */

(values were taken from https://www.opengl.org/registry/api/GL/glxext.h)

And the following defines in wglew.h:

/* --------------------- WGL_ARB_context_flush_control --------------------- */

#ifndef WGL_ARB_context_flush_control
#define WGL_ARB_context_flush_control 1

#define WGL_CONTEXT_RELEASE_BEHAVIOR_ARB  0x2097
#define WGL_CONTEXT_RELEASE_BEHAVIOR_NONE_ARB 0
#define WGL_CONTEXT_RELEASE_BEHAVIOR_FLUSH_ARB 0x2098

#define WGLEW_ARB_context_flush_control WGLEW_GET_VAR(__WGLEW_ARB_context_flush_control)

#endif /* WGL_ARB_context_flush_control */

(values were taken from https://www.opengl.org/registry/api/GL/wglext.h)

When I use dylibs (libGLEW.1.13.0.dylib) made from the zip file from the glew website, my code runs nice and pretty but when I compile my own from this git repo, Xcode throws a shitload of redefinition errors.

Aren't these exactly the same or it there a difference?

I am using Xcode6.2 and OSX 10.10, I try almost all the instructions of glew configuration on the internet and it turns out that compiler keep telling me that can't find glew.h
Is there any solutions ?

src folder only contains visualinfo.c but not glew.c and glewinfo.c. They also aren't present in the sourceforge git repo either. These are present in the .zip download however.

The bare makefile installs versioned libraries, but the cmakefile doesn't.

Hi Nigel et al.,

I'm trying to use GLEW from git to get EGL. It looks like GLEW is redefining e.g. "eglGetDisplay", but it never actually loads the function pointer.
Is it just that the support is currently incomplete? What is the current status?

Thanks!

Knowing that GLEW is a quite mature library, i understand that the build system is solid and stable at this point.

However, lots of projects use CMake as their build tool, which makes easy problems like multi-platformness (i was not ready for the 'config' directory) quite a painless task, and allow to make different build systems in a breeze.

There are some attempts at GitHub already:

• https://github.com/no1msd/glew
• https://github.com/menpo/glew
• https://github.com/omniavinco/glew-cmake

Is there something that you don't like (assuming the file is tested, and has all the functionality that the Makefile has) about the idea? Or is that assumption not being true what stops the merging of such a file?

Thanks for the amazing work.

Hey
i'm using glew and glfw3.
In my code, I init glfw3 first, then I create a window and its context, and then I try to initialize glew.
I get the "missing gl version" error.
I compiled on windows sources myself.
Here are my preprocessors for compiling glfw :

_GLFW_WIN32;_GLFW_WGL;_GLFW_USE_OPENGL;_GLFW_BUILD_DLL;

and for glew :

WIN32;WIN32_LEAN_AND_MEAN;VC_EXTRALEAN;GLEW_BUILD;

Here is my code :

`GLFWwindow* window;
glfwSetErrorCallback(error_callback);
    if (!glfwInit())
    exit(EXIT_FAILURE);
window = glfwCreateWindow(640, 480, "Simple example", NULL, NULL);
if (!window)
{
    glfwTerminate();
    exit(EXIT_FAILURE);
}
glfwMakeContextCurrent(window);
std::cout << glGetString(GL_VERSION) << std::endl;

glewExperimental = true;
GLenum err = glewInit();
if (err != GLEW_OK) {
    std::cerr << "Failed to init GLEW !" << std::endl << glewGetErrorString(err) << std::endl;
    glfwTerminate();
    return 1;
}`

glGetString(GL_VERSION) does return my opengl version ! (4.5.0)
And I tried with glewExperimental = false too

After some debugging, I found that this is causing the error :
getString = (PFNGLGETSTRINGPROC) glewGetProcAddress((const GLubyte*)"glGetString"); if (!getString) return GLEW_ERROR_NO_GL_VERSION;
That means glew can't get that string...

Can somebody help me please ?

GLEW_VERSION, GLEW_VERSION_MAJOR, GLEW_VERSION_MINOR, GLEW_VERSION_MICRO vars in glew_tail.h seem to have incorrect values

If you were looking for glew using cmake instead of make. (Saw cmake-testbuild.sh popping up in your repo)
https://github.com/Perlmint/glew-cmake this project did it pretty well.

I noticed I could generate a perfectly working project in the same fashion I did with the opengl-boilerplate.
Instead I used this guys repo which I find a bit more interesting than the opengl-boilerplate.
https://github.com/ArthurSonzogni/OpenGL_CMake_Skeleton

Could've forked your version of glew and simply copy paste the cmake file but I don't want to take credit for something I didn't put my effort into.

Hope it helps for your cmake test build

I'm using GLEW for my OpenGL project and primary development platform is Windows. I use forward OpenGL 4.0 context and all work just fine on Windows.

When I ported code to OS X some of core functions seems not to be initialized (are NULL). For example, glGenSamplers (which is definitely core function in 4x) throws EXC_BAD_ACCESS. I tried to create 3x and 4x contexts (with NSOpenGLContext) - both give same error. However, when I use standard gl3.h header (OpenGL/gl3.h) instead of using GLEW all core functions work ok, so this is not hardware or driver issue.

My OS X version is 10.10.2 (Yosemite) and video card is AMD R9 280X

I have cd'd into the directory of the downloaded zip and ran "make all", followed by "sudo -s" and "make install.all" multiple times.

Running bin/glewinfo returns "OK" for a lot of the functions but "MISSING" for a lot of them and Eclipse fails to compile the project with the following error.

14:08:51 **** Incremental Build of configuration Debug for project Prototype-RP ****
make all
Building target: Prototype-RP
Invoking: MacOS X C++ Linker
g++ -o "Prototype-RP" ./src/Prototype-RP.o
Undefined symbols for architecture x86_64:
"_glewExperimental", referenced from:
_main in Prototype-RP.o
"_glewInit", referenced from:
_main in Prototype-RP.o
"_glfwCreateWindow", referenced from:
_main in Prototype-RP.o
"_glfwInit", referenced from:
_main in Prototype-RP.o
"_glfwMakeContextCurrent", referenced from:
_main in Prototype-RP.o
"_glfwPollEvents", referenced from:
_main in Prototype-RP.o
"_glfwSwapBuffers", referenced from:
_main in Prototype-RP.o
"_glfwTerminate", referenced from:
_main in Prototype-RP.o
"_glfwWindowHint", referenced from:
_main in Prototype-RP.o
"_glfwWindowShouldClose", referenced from:
_main in Prototype-RP.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Prototype-RP] Error 1

Any help is appreciated.

Hi,
with the removal of MX support and added core, it would be nice to convert from the macro usage to inline functions. Currently am doing this in "post" by parsing the glew headers and replacing the macros with some lua scripts, but it would be nice if the stock GLEW offers this functionality. I've also added a GLEW_USER_ASSERT macro that can be defined optionally, to prevent calling a NULL function pointer.

GLEW_FUN_EXPORT PFNGLNAMEDPROGRAMLOCALPARAMETERI4IEXTPROC __glewNamedProgramLocalParameterI4iEXT;
__inline void glNamedProgramLocalParameterI4iEXT(GLuint program,GLenum target,GLuint index,GLint x,GLint y,GLint z,GLint w){
GLEW_USER_ASSERT(__glewNamedProgramLocalParameterI4iEXT);
__glewNamedProgramLocalParameterI4iEXT(program,target,index,x,y,z,w);}

one benefit of inline is that it works well with showing the function arguments in IDEs

Fix so it can be compiled by using MinGW. Or rather, src/glew.c cannot be generated and needs to be in the git repo.

https://www.opengl.org/registry/specs/ARB/sparse_buffer.txt defines NamedBufferPageCommitmentARB as an intersection with ARB_dsa extension but the function is not defined in GLEW 1.12.

Thanks,
Christophe

Hi,

I was setting up the GLEW MX and I found the setup instructions a bit confusing. Namely which threads should create the GLEWContext objects, which should initialize them and exactly when the association with a thread and rendering context is made.

As far as I understand (and what worked for me) is the following:

• Each GLEWContext has to be associated with a rendering context and a thread which will be using it.
• The creation of GLEWContext does nothing more than allocated space for it. It does not associate it with the running thread or with the current rendering context. There can be no current rendering context in fact.
• The association with the rendering context and thread is done by a call to glewInit. This call should be made from the thread that will be using the GLEWContext. Additionally the method glewGetContext() should return the GLEWContext to be initialized and the proper rendering context needs to be active.
• The call to glewInit has to be made for every GLEWContext to be used in the rendering thread (which implies using separate rendering context for each one of them).

Now the last point I find to be disputable since things seem to work if I initialize any one GLEWContext from a rendering thread despite using multiple rendering contexts and multiple GLEWContext.

Overall some or all of this info should be added to documentation to make it more clear.

I have a CMake project that adds GLEW as an external project

externalProject_add(glew
    GIT_REPOSITORY https://github.com/nigels-com/glew.git
    GIT_TAG glew-1.12.0
    SOURCE_DIR build/cmake
    INSTALL_DIR ${glew_INSTALL_DIR})

When I go to build with Make I get this error

[  5%] Performing update step for 'glew'
[ 11%] Performing configure step for 'glew'
-- checking for module 'gl'
--   package 'gl' not found

This is odd because I know I have OpenGL

$ ~ glxinfo | grep gl
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GL_ARB_texture_rectangle, GL_ARB_texture_storage, GL_ARB_texture_swizzle, 
    GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, 
    GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_OES_EGL_image,

$ ~ glxinfo | grep '^direct rendering:'
direct rendering: Yes

I build the static glew library glew32sd.lib using vc12. When I want to link to glew in my project, there are errors:
1>main.obj : error LNK2019: unresolved external symbol __imp_glGetString referenced in function "void __cdecl setup_openGL(void)" (?setup_openGL@@yaxxz)
1>main.obj : error LNK2019: unresolved external symbol __imp_glewInit referenced in function "void __cdecl setup_openGL(void)" (?setup_openGL@@yaxxz)
1>main.obj : error LNK2001: unresolved external symbol __imp___GLEW_VERSION_3_2
1>main.obj : error LNK2001: unresolved external symbol __imp_glewExperimental

I have set the correct path for glew. What's the problem?

several warnings are spotted by this compilation flag, i.e:

../../dcvtest/glew.cpp: In function ‘const GLubyte* glewGetErrorString(GLenum)’:
../../dcvtest/glew.cpp:13535:76: warning: conversion to ‘int’ from ‘long unsigned int’ may alter its value [-Wconversion]
const int max_error = sizeof(_glewErrorString)/sizeof(_glewErrorString) - 1;
^
../../dcvtest/glew.cpp: In function ‘const GLubyte glewGetString(GLenum)’:
../../dcvtest/glew.cpp:13549:67: warning: conversion to ‘int’ from ‘long unsigned int’ may alter its value [-Wconversion]
const int max_string = sizeof(_glewString)/sizeof(*_glewString) - 1;

My Source code:

#include <iostream>
#define GLEW_STATIC
#include <GL/glew.h>
// GLFW
#define GLFW_INCLUDE_GLCOREARB
#include <GLFW/glfw3.h>

int main(int argc, const char * argv[]) {
    glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
    glfwInit();

    return 0;
}

Undefined symbols for architecture x86_64:
"_glfwInit", referenced from:
_main in main.o

I'm on Linux 3.16, MESA OpenGL driver 10.1.3, using OpenGL 3+ and none of the extensions can be detected by GLEW because glGetString(GL_EXTENTIONS) returns NULL on my system:

  /* query opengl extensions string */
  extStart = glGetString(GL_EXTENSIONS);

if I do this, it works fine:

    GLint n;
    glGetIntegerv(GL_NUM_EXTENSIONS, &n);
    if (n > 0)
    {
        const char** extensions = (const char**)malloc(n * sizeof(char*));
        GLint i;
        for (i = 0; i < n; i++)
        {
            extensions[i] = (char*)glGetStringi(GL_EXTENSIONS, i);
        }
    }

Tried it via make

14:01:33 warmwaffles@~/code/c/glew (master) : make -C auto clobber
make: Entering directory '/home/warmwaffles/code/c/glew/auto'
rm -rf ../include/GL/glew.h ../include/GL/wglew.h ../include/GL/glxew.h ../include/GL/eglew.h ../src/glew.c ../src/glewinfo.c ../doc/index.html ../doc/install.html ../doc/basic.html ../doc/advanced.html ../doc/build.html ../doc/credits.html ../doc/log.html ../doc/glew.html ../doc/wglew.html ../doc/glxew.html ../build/glew.rc ../build/glewinfo.rc ../build/visualinfo.rc
rm -rf extensions/gl
make: Leaving directory '/home/warmwaffles/code/c/glew/auto'
14:01:38 warmwaffles@~/code/c/glew (master) : make extensions
make -C auto
make[1]: Entering directory '/home/warmwaffles/code/c/glew/auto'
--------------------------------------------------------------------
Creating descriptors
--------------------------------------------------------------------
rm -rf extensions/gl
bin/update_ext.sh extensions/gl registry/gl/specs blacklist
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 356.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 360.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 356.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 360.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 356.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 360.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 356.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 360.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 356.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 360.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 356.
Hexadecimal number > 0xffffffff non-portable at bin/parse_spec.pl line 360.
python bin/parse_xml.py registry/xml/egl.xml --core core/gl --extensions extensions/gl
  File "bin/parse_xml.py", line 117
    print 'Found {} enums, {} commands, {} features and {} extensions.'.format(
                                                                      ^
SyntaxError: invalid syntax
Makefile:117: recipe for target 'extensions/gl/.dummy' failed
make[1]: *** [extensions/gl/.dummy] Error 1
make[1]: Leaving directory '/home/warmwaffles/code/c/glew/auto'
Makefile:342: recipe for target 'extensions' failed
make: *** [extensions] Error 2

Then via cmake

14:02:16 warmwaffles@~/code/c/glew/build (master) : cmake ./cmake/
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenGL: /usr/lib64/libGL.so  
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib64/libX11.so
-- Configuring done
CMake Error at CMakeLists.txt:89 (add_library):
  Cannot find source file:

    /home/warmwaffles/code/c/glew/include/GL/wglew.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx


CMake Error at CMakeLists.txt:160 (add_executable):
  Cannot find source file:

    /home/warmwaffles/code/c/glew/src/glewinfo.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx


CMake Error: CMake can not determine linker language for target: glew
CMake Error: Cannot determine link language for target "glew".
CMake Error: Cannot determine link language for target "glew_s".
CMake Error: CMake can not determine linker language for target: glew_s
CMake Error: CMake can not determine linker language for target: glewinfo
CMake Error: Cannot determine link language for target "glewinfo".
CMake Error: CMake can not determine linker language for target: glew
CMake Error in CMakeLists.txt:
  Exporting the target "glew" is not allowed since its linker language cannot
  be determined


CMake Error in CMakeLists.txt:
  Exporting the target "glew" is not allowed since its linker language cannot
  be determined


CMake Error: CMake can not determine linker language for target: glew_s
CMake Error in CMakeLists.txt:
  Exporting the target "glew_s" is not allowed since its linker language
  cannot be determined


CMake Error in CMakeLists.txt:
  Exporting the target "glew_s" is not allowed since its linker language
  cannot be determined


-- Generating done
-- Build files have been written to: /home/warmwaffles/code/c/glew/build

My assumption was that all I would need to do is just clone the directory and it should just compile. 1.13.0 compiles just fine.

It looks like the vertex array object function pointers (glGenVertexArrays, glDeleteVertexArrays, glBindVertexArray) are not setup as part of glewInit() on GL 3.0 and up. These functions should be available as vanilla GL functions from GL 3.0 and up (see https://www.opengl.org/registry/doc/glspec30.20080811.pdf). I noticed this on OSX when setting up a 3.2 core profile context (but on the other hand, GLEW is redundant in this scenario, since the core profile doesn't expose any extensions). It still might be a bug in GLEW though.

several warnings are spotted using this warning, i.e:

../../dcvtest/glew.cpp: In function ‘GLboolean glxewIsSupported(const char_)’:
../../dcvtest/glew.cpp:17755:28: warning: cast from type ‘const char_’ to type ‘GLubyte* {aka unsigned char_}’ casts away qualifiers [-Wcast-qual]
GLubyte_ pos = (GLubyte*)name;
^

Hi,

In glew-20160131.tgz the defines are missing the letters. In glew.h you find:

define GL_ALPHA_REF_COMMAND_NV 0x000

define GL_BLEND_COLOR_COMMAND_NV 0x000

define GL_LINE_WIDTH_COMMAND_NV 0x000

define GL_POLYGON_OFFSET_COMMAND_NV 0x000

define GL_STENCIL_REF_COMMAND_NV 0x000

define GL_TERMINATE_SEQUENCE_COMMAND_NV 0x0000

define GL_UNIFORM_ADDRESS_COMMAND_NV 0x000

where, according to the extension specs, it should be:

define GL_UNIFORM_ADDRESS_COMMAND_NV 0x000a

define GL_BLEND_COLOR_COMMAND_NV 0x000b

define GL_STENCIL_REF_COMMAND_NV 0x000c

define GL_LINE_WIDTH_COMMAND_NV 0x000d

define GL_POLYGON_OFFSET_COMMAND_NV 0x000e

define GL_ALPHA_REF_COMMAND_NV 0x000f

Keep up the excellent work :-)

Best Regards,

António

I discovered this problem as I was porting my application that was buillt with GLEW 1.10 and the new machine had GLEW 1.12.
This resulted in an shared library loading error where the application required glew 1.10 but the system had glew 1.12.

I realized that this issue is because there is no symlink between libglew.so -> libglew.so.1.12 (the symlink in between should be libglew.so.1). If the so.1 were present, my application would have only required so.1 and would have then worked with either 1.10 or 1.12 or any other version.

The current symlinks for the SO versions are as below:

~$ ls -l /usr/lib/x86_64-linux-gnu/libGLEW*
/usr/lib/x86_64-linux-gnu/libGLEWmx.so -> libGLEWmx.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10 -> libGLEWmx.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEW.so -> libGLEW.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10 -> libGLEW.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0

The standard way most libraries symlink is
libname.so -> libname.so.major
libname.so.major -> libname.so.major.minor
libname.so.major .minor-> libname.so.major.minor.micro

This means there should be an intermediate libGLEW.so.1 symlink.

I am trying to change this. But given the number of different platforms available in the makefiles, it make take some time getting this done.

Here is my code http://pastie.org/8392206

Compile was success, but then on run it fails with error "invalid enumerant"

The top of the makefile says to set STRIP='' to stop the binaries from being stripped. However the binaries (as installed by install.bin) uses install -s instead of $(STRIP) so they're always stripped.

I've followed http://glew.sourceforge.net/install.html and still receiving errors. Linked project with glew32.lib, glu32.lib, and opengl32.lib on Windows. What is going on?

#include <cmath>
#include <iostream>
#include <sstream>
#include <vector>
#include "vecmath.h"
#include <fstream>
#include <GL/glew.h>
#include <GL/glut.h>
#include "GL/freeglut.h"
#define GL_GLEXT_PROTOTYPES
#include <GL/glext.h>
#include <gl\GL.h>
#include <gl\GLU.h>
using namespace std;

How would you go about compiling these through VS - i can easily get glew32s.lib but no glew32.lib.\

Thanks!

I spent a little while researching why you can't pull glew from this repo and build it. Perhaps a few words in the Readme explaining that if you want to just get going, you should pull the tar ball from sourceforge, and that the repo here is only for use if you intend to generate the glew source code. Perhaps start the readme with

If you obtained the source from github you will need to make extensions, as the generated source is not included. If you wish to proceed immediately to installing glew, please obtain the tarball from sourceforge.

Such a paragraph would no doubt save several users from a little bit of puzzle solving.

New extensiones have just posted on opengl registry and glext.h just updated.. Can you update glew for supporting it? Thanks..

My machine is Ubuntu 14.04 and glew 1.10 comes along with it by default because the unity ubuntu desktop came along with it. If I want to use the latest glew 1.13, what is the best way for me to remove glew 1.10 safely?

I downloaded the code using git and try to build glew from it. The commands used were

export GLEW_DEST=/usr/local/glew
make extensions
make

and the resulting error is

ld: dylib lib/libGLEW.dylib missing LC_ID_DYLIB load command file 'lib/libGLEW.dylib' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

am I doing something wrong during the compilation?

8(

GLEW is reporting ARB_texture_storage as unsupported on OS X 10.9, even though it is. Upon further inspection it looks like it's doing so because the EXT_direct_state_access functions included in the extension aren't implemented.

Since the ARB_texture_storage spec only specifies those functions to exist when EXT_direct_state_access is present as well, I don't think GLEW should be marking the whole extension as unsupported in this case.

After being able to build glew as described in issue #47 , I tried to link the resulting library, libGLEW.a with my application and got the following output

Linking CXX executable Luzoso
ld: warning: ignoring file /usr/local/glew/lib/libGLEW.a, file was built for archive which is not the architecture being linked (x86_64): /usr/local/glew/lib/libGLEW.a
Undefined symbols for architecture x86_64:
  "___glewAttachShader", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewBindBuffer", referenced from:
      SimpleTriangle::SimpleTriangle() in SimpleTriangle.cpp.o
      SimpleCube::SimpleCube() in SimpleCube.cpp.o
  "___glewBindVertexArray", referenced from:
      SimpleTriangle::SimpleTriangle() in SimpleTriangle.cpp.o
      SimpleTriangle::render() in SimpleTriangle.cpp.o
      SimpleCube::SimpleCube() in SimpleCube.cpp.o
      SimpleCube::render() in SimpleCube.cpp.o
  "___glewBufferData", referenced from:
      SimpleTriangle::SimpleTriangle() in SimpleTriangle.cpp.o
      SimpleCube::SimpleCube() in SimpleCube.cpp.o
  "___glewCompileShader", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewCreateProgram", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewCreateShader", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewDeleteShader", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewEnableVertexAttribArray", referenced from:
      SimpleTriangle::SimpleTriangle() in SimpleTriangle.cpp.o
      SimpleCube::SimpleCube() in SimpleCube.cpp.o
  "___glewGenBuffers", referenced from:
      SimpleTriangle::SimpleTriangle() in SimpleTriangle.cpp.o
      SimpleCube::SimpleCube() in SimpleCube.cpp.o
  "___glewGenVertexArrays", referenced from:
      SimpleTriangle::SimpleTriangle() in SimpleTriangle.cpp.o
      SimpleCube::SimpleCube() in SimpleCube.cpp.o
  "___glewGetProgramInfoLog", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewGetProgramiv", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewGetShaderInfoLog", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewGetShaderiv", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewGetUniformLocation", referenced from:
      _main in Luzoso.cpp.o
  "___glewLinkProgram", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewShaderSource", referenced from:
      Shader::Shader(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in Shader.cpp.o
  "___glewUniformMatrix4fv", referenced from:
      _main in Luzoso.cpp.o
  "___glewUseProgram", referenced from:
      Shader::use() in Shader.cpp.o
  "___glewVertexAttribPointer", referenced from:
      SimpleTriangle::SimpleTriangle() in SimpleTriangle.cpp.o
      SimpleCube::SimpleCube() in SimpleCube.cpp.o
  "_glewExperimental", referenced from:
      _main in Luzoso.cpp.o
  "_glewInit", referenced from:
      _main in Luzoso.cpp.o
ld: symbol(s) not found for architecture x86_64

when I clone the repo and simply type make, the error is shown below

make: *** No rule to make target src/glew.c', needed bytmp/linux/default/shared/glew.o'. Stop.

It seems that there is no glew.c exist in the src folder, can someone help? Thanks

OS: Linux (openSUSE_Tumbleweed)

git checkout origin/master

HEAD is now at 180db26... cmake fixup for non-Windows

git clean -fdx

make

mkdir lib
make: *** No rule to make target 'src/glew.c', needed by 'tmp/linux/default/shared/glew.o'. Stop.

git clean -fdx && cd build

cmake ./cmake

-- The C compiler identification is GNU 5.3.1
-- The CXX compiler identification is GNU 5.3.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenGL: /usr/lib64/libGL.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib64/libX11.so
-- Configuring done
CMake Error at CMakeLists.txt:89 (add_library):
Cannot find source file:

/source/dri-project/glew/include/GL/wglew.h

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

CMake Error at CMakeLists.txt:160 (add_executable):
Cannot find source file:

/source/dri-project/glew/src/glewinfo.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

CMake Error: CMake can not determine linker language for target: glew
CMake Error: Cannot determine link language for target "glew".
CMake Error: Cannot determine link language for target "glew_s".
CMake Error: CMake can not determine linker language for target: glew_s
CMake Error: CMake can not determine linker language for target: glewinfo
CMake Error: Cannot determine link language for target "glewinfo".
CMake Error: CMake can not determine linker language for target: glew
CMake Error in CMakeLists.txt:
Exporting the target "glew" is not allowed since its linker language cannot
be determined

CMake Error in CMakeLists.txt:
Exporting the target "glew" is not allowed since its linker language cannot
be determined

CMake Error: CMake can not determine linker language for target: glew_s
CMake Error in CMakeLists.txt:
Exporting the target "glew_s" is not allowed since its linker language
cannot be determined

CMake Error in CMakeLists.txt:
Exporting the target "glew_s" is not allowed since its linker language
cannot be determined

-- Generating done
-- Build files have been written to: /source/dri-project/glew/build

in your make install. I'll grant your laziness on Cmake out of tree building being useless, but polluting the /usr/ and not installing default under /usr/local/ is pathetic.

Debian/Ubuntu/Mint: $ sudo apt-get install build-essential libXmu-dev libXi-dev libgl-dev git

should be:
Debian/Ubuntu/Mint: $ sudo apt-get install build-essential libxmu-dev libxi-dev libgl-dev git

(small caps)

One cannot use the static glew library from a CMake project because CMake's built-in FindGLEW.cmake prefers the shared library.

The official CMake-way is to allow the variable BUILD_SHARED_LIBS control whether to build shared or static lib and build only either one.

Another related problem is that FindGLEW.cmake never defines GLEW_STATIC. The solution is to install a config-module which is aware of the shared/static versions and defines GLEW_STATIC accordingly.

I will implement these changes but let me know if you're interested in such a change and if yes, I'd like to follow your preferences about the details:

• I would modify CMakeLists.txt to observe BUILD_SHARED_LIBS:
  • I can remove the option to build shared+static together (my preference)
  • I can leave the default behaviour as it is (build shared+static) and introduce GLEW_OBSERVE_BUILD_SHARED_LIBS with default value OFF
  • or introduce GLEW_OBSERVE_BUILD_SHARED_LIBS with default value ON
• I would install a config-module glew-config.cmake to <prefix>/lib/cmake which defines GLEW_STATIC if needed

I was trying to use cmake and the provided VS12 solution but got the following errors.

Command to build with cmake and results
cmake -G "Visual Studio 12 2013 Win64" ./cmake

$ cmake -G "Visual Studio 12 2013 Win64" ./cmake
-- The C compiler identification is MSVC 18.0.21005.1
-- The CXX compiler identification is MSVC 18.0.21005.1
-- Check for working C compiler using: Visual Studio 12 2013 Win64
-- Check for working C compiler using: Visual Studio 12 2013 Win64 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 12 2013 Win64
-- Check for working CXX compiler using: Visual Studio 12 2013 Win64 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenGL: opengl32
-- Configuring done
CMake Error at CMakeLists.txt:89 (add_library):
Cannot find source file:

C:/Users/Me/Github/glew/include/GL/wglew.h

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

CMake Error at CMakeLists.txt:160 (add_executable):
Cannot find source file:

C:/Users/Me/Github/glew/src/glewinfo.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

CMake Error at CMakeLists.txt:170 (add_executable):
Cannot find source file:

C:/Users/Me/Github/glew/build/visualinfo.rc

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

CMake Error: CMake can not determine linker language for target: glewinfo
CMake Error: CMake can not determine linker language for target: glew_s
CMake Error: CMake can not determine linker language for target: visualinfo
CMake Error: CMake can not determine linker language for target: glew
CMake Error: CMake can not determine linker language for target: glew
CMake Error in CMakeLists.txt:
Exporting the target "glew" is not allowed since its linker language cannot
be determined

CMake Error: CMake can not determine linker language for target: glew
CMake Error in CMakeLists.txt:
Exporting the target "glew" is not allowed since its linker language cannot
be determined

CMake Error: CMake can not determine linker language for target: glew
CMake Error in CMakeLists.txt:
Exporting the target "glew" is not allowed since its linker language cannot
be determined

CMake Error: CMake can not determine linker language for target: glew
CMake Error in CMakeLists.txt:
Exporting the target "glew" is not allowed since its linker language cannot
be determined

CMake Error: CMake can not determine linker language for target: glew
CMake Error in CMakeLists.txt:
Exporting the target "glew" is not allowed since its linker language cannot
be determined

CMake Error: CMake can not determine linker language for target: glew_s
CMake Error in CMakeLists.txt:
Exporting the target "glew_s" is not allowed since its linker language
cannot be determined

CMake Error: CMake can not determine linker language for target: glew_s
CMake Error in CMakeLists.txt:
Exporting the target "glew_s" is not allowed since its linker language
cannot be determined

CMake Error: CMake can not determine linker language for target: glew_s
CMake Error in CMakeLists.txt:
Exporting the target "glew_s" is not allowed since its linker language
cannot be determined

CMake Error: CMake can not determine linker language for target: glew_s
CMake Error in CMakeLists.txt:
Exporting the target "glew_s" is not allowed since its linker language
cannot be determined

CMake Error: CMake can not determine linker language for target: glew_s
CMake Error in CMakeLists.txt:
Exporting the target "glew_s" is not allowed since its linker language
cannot be determined

-- Generating done
-- Build files have been written to: C:/Users/Me/Github/gle
w/build

Results from VS12 provided solution
1>------ Build started: Project: glew_static, Configuration: Debug Win32 ------
2>------ Build started: Project: glew_shared, Configuration: Debug Win32 ------
1> glew.c
1>c1 : fatal error C1083: Cannot open source file: '....\src\glew.c': No such file or directory
2> glew.c
2>c1 : fatal error C1083: Cannot open source file: '....\src\glew.c': No such file or directory
3>------ Build started: Project: glewinfo, Configuration: Debug Win32 ------
4>------ Build started: Project: visualinfo, Configuration: Debug Win32 ------
4> visualinfo.c
3> glewinfo.c
3>c1 : fatal error C1083: Cannot open source file: '....\src\glewinfo.c': No such file or directory
4>....\src\visualinfo.c(36): fatal error C1083: Cannot open include file: 'GL/glew.h': No such file or directory
========== Build: 0 succeeded, 4 failed, 0 up-to-date, 0 skipped ==========

I remember compiling on Mac OS and executing make extensions before attempting cmake and it worked. Actually, the aforementioned command created a directory called include that is not present when build on windows with cmake or vs. What should I do be able to do make extensions but in windows to build from source?

Cheers