ofiwg/libfabric#7041 (comment)

We made this change very recently in microsoft/STL#2148 which forbids including standard library headers from C programs.

I can't build with gl3w anymore in VS 2022 17.1 and MSVC toolset 143

a simple fix would be to change the c extension to cpp

Hi,

In my project, when i init OpenGL with gl3wInit i have an error : GL3W_ERROR_OPENGL_VERSION

The code below (get from here) return strange value. I have put it in the parse_version function.

int major, minor;
glGetIntegerv(GL_MAJOR_VERSION, &major);
glGetIntegerv(GL_MINOR_VERSION, &minor);
printf("%d.%d\n", major, minor);

printf return : 0.1275

any solution ? Thanks for help

Greetings,

This is a question more than an issue. I was just wondering about something. In the generated code we have:

in gl3w.h
extern PFNGLACTIVESHADERPROGRAMPROC gl3wActiveShaderProgram;
...

define glActiveShaderProgram gl3wActiveShaderProgram

...
in gl3w.c
PFNGLACTIVESHADERPROGRAMPROC gl3wActiveShaderProgram;

Why not just:
in gl3w.h
extern PFNGLACTIVESHADERPROGRAMPROC glActiveShaderProgram;

in gl3w.c
PFNGLACTIVESHADERPROGRAMPROC glActiveShaderProgram;

I did that and everything's still working. I'm not sure what is achieved by that extra layer.

Hello!

First of all, great library! I was planning on doing exactly this for my project and it's great to see that somebody already had this idea and nicely executed it.

I tried adding this as-is to my project using either CMake's FetchContent or a normal add_subdirectory call, but both lead to the same problem when making an linking gl3w after an add_library: it says it's missing the gl3w.c file.

I believe that's because the .c and .h files generated by the Python script is done so at the build time, and this checking is happening at configure time, so they are not there yet. If I run the script myself beforehand everything compiles fine.

I am not an expert at this, but is it possible to make the file generation happen just once at configure time? This would make embedding gl3w into newer projects more straight forward.

If it matters, I am on Windows, using CMake version 3.17.0-rc1 with MSVC 16.5.1. If any more information is needed I am happy to provide them.

Thanks!

Hi,
In order to work on all platforms, do you need to call gl3wInit once for every opengl context or possibly for every context switch or is one call on the first gl context sufficient?
Thanks you!

when I call glCreateBuffers with Xcode on Mac, it send error: Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)

does gl3w support loading core context from opengles as well?

I couldn't find any information on the Github page to say which Python version is needed for gl3w (it looks to be Python 2.x). It would be good to have this documented somewhere obvious for people (like me) who know little about Python versions.

Since I installed Python 3.4 first, I thought I would modify gl3w_gen.py to make it work, rather than installing Python 2. I can submit these changes as a pull request, if there is a chance of them getting merged somehow.

Hi guys,
Recently, we got some regression when building gl3w on vcpkg pipeline test.
Here is the error log:

Traceback (most recent call last):
  File "urllib\request.py", line 1346, in do_open
  File "http\client.py", line 1253, in request
  File "http\client.py", line 1299, in _send_request
  File "http\client.py", line 1248, in endheaders
  File "http\client.py", line 1008, in _send_output
  File "http\client.py", line 948, in send
  File "http\client.py", line 1422, in connect
  File "ssl.py", line 500, in wrap_socket
  File "ssl.py", line 1040, in _create
  File "ssl.py", line 1309, in do_handshake
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\buildtrees\gl3w\src\5f10c86132-7e24c6e824.clean\gl3w_gen.py", line 115, in <module>
    web = urllib2.urlopen('https://www.khronos.org/registry/EGL/api/KHR/khrplatform.h')
  File "urllib\request.py", line 214, in urlopen
  File "urllib\request.py", line 517, in open
  File "urllib\request.py", line 534, in _open
  File "urllib\request.py", line 494, in _call_chain
  File "urllib\request.py", line 1389, in https_open
  File "urllib\request.py", line 1349, in do_open
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)>

But sadly, we couldn't reproduce this issue locally.

Maybe you should disable the certificiation check.

Related: microsoft/vcpkg#18846 microsoft/vcpkg#18194

Take Windows as an example. The function pointers are retrieved in get_proc(). It first tries to retrieve a function pointer from wglGetProcAddress, assuming it is an extension. If not, it then find it in opengl32.dll using GetProcAddress. However, the return value of GetProcAddress is not checked, which seems to be assuming that the function must be in opengl32.dll. But on what is this assumption based? What if an OpenGL function is neither in opengl32.dll nor from wglGetProcAddress?

PS: the current code of get_proc():

static GL3WglProc get_proc(const char *proc)
{
	GL3WglProc res;

	res = (GL3WglProc)wgl_get_proc_address(proc);
	if (!res)
		res = (GL3WglProc)GetProcAddress(libgl, proc);
	return res;
}

When the generated glcorearb.h is used with modules enabled on OS X the compiler catches an error that is not normally caught: C++ disallows including C++ standard library headers inside extern "C" blocks, but "no diagnostic is required."

[using.headers]p3: "A translation unit shall include a header only outside of any external declaration or definition, and shall include the header lexically before the first reference in that translation unit to any of the entities declared in that header. No diagnostic is required."

With modules on OS X the compiler does produce an error diagnostic:

glcorearb.h:616:1: error: import of C++ module 'Darwin.C.stddef' appears within extern "C" language linkage specification

include <stddef.h>

^
glcorearb.h:5:1: note: extern "C" language linkage specification begins here
extern "C" {
^
glcorearb.h:1517:1: error: import of C++ module 'Darwin.C.inttypes' appears within extern "C" language linkage specification

include <inttypes.h>

^
glcorearb.h:5:1: note: extern "C" language linkage specification begins here
extern "C" {
^

Here's an email with some discussion of the issue and modules:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039396.html

Khronos generates their GL headers (including glcorearb.h) from XML files using a Python script (https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/genheaders.py).

Would it make sense for gl3w to parse the structured XML directly, rather than interpreting the generated headers? Less scope for error imho.

Downloading glcorearb.h to include/GL...
Traceback (most recent call last):
File "C:\luaGL\gl3w-master\gl3w_gen.py", line 84, in
context = ssl._create_unverified_context()
AttributeError: 'module' object has no attribute '_create_unverified_context'

Hi,

I'm building gl3w adding the following line to my CMakeLists.txt

add_subdirectory(gl3w)

but I've got the following error:

CMake Error: File /home/user/testdit/gl3w/cmake/Project-config.cmake does not exist.
CMake Error at gl3w/CMakeLists.txt:65 (configure_file):
configure_file Problem configuring file

I can reproduce the issue creating a directory tree like the following

testdir/gl3w
testdir/CMakeLists.txt
testdir/build

CMakeLists.txt has only one line
add_subdirectory(gl3w)

from the build directory
invoking
cmake ..

will generate the error

Any idea on why this is happening?

I'm using cmake 3.7.1

Thanks a lot!

I'm using the fix for issue #11 "Error in compilation invalid conversion from (void_)() to void_" which was fixed in issue #12 (I'm using the fork that has it fixed that requested a pull). But now I'm getting "Error in compilation invalid conversion from void* to void(*)() on the line "res = dlsym(libgl, proc)" below. It's line 82 in gl3w.cpp. I'm also using g++ and Linux.

static gl3wProc *get_proc(const char *proc)
{
gl3wProc *res;

res = glXGetProcAddress((const GLubyte *) proc);
if (!res)
    res = dlsym(libgl, proc);  //<------ THIS LINE HAS THE ERROR
return res;

}

when I using the gl3w , I encountered these errors.Someone can help me .Thank you very much.

It would be helpful if there are releases/tags for versions that are in a production ready state and to indicate when there are major tested changes that can be incorporated in other codes.

Hey!

I'm building a multi-threaded OpenGL application and require gl3wProcs to be thread local storage (so i can use multiple contexts with each their own function pointers).

I don't have a patch, but the only thing that must be changed is two lines of code:

// gl3w.h:
extern _Thread_local union GL3WProcs gl3wProcs; // added _Thread_local here

// gl3w.c:
_Thread_local union GL3WProcs gl3wProcs; // added _Thread_local here

This feature could also be optional with a preprocessor option GL3W_THREAD_LOCAL or similar...

Regards
Felix

The script was working recently (like 15 days ago or less), but yesterday and today I got a weird error

Downloading glcorearb.h to include/GL...
Traceback (most recent call last):
  File "gl3w_gen.py", line 83, in <module>
    web = urllib2.urlopen('https://www.opengl.org/registry/api/GL/glcorearb.h')
  File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 429, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 447, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1241, in https_open
    context=self._context)
  File "/usr/lib/python2.7/urllib2.py", line 1198, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)>

I have no idea if this comes from me, from gl3w_gen.py or from opengl.org, but it would be great if I could get it working again, do you have any ideas where I could start ?

Thanks

EDIT:
I got it working by using this link : http://stackoverflow.com/a/28052583/4717805

I replaced

# Download glcorearb.h
if not os.path.exists('include/GL/glcorearb.h'):
    print('Downloading glcorearb.h to include/GL...')
    web = urllib2.urlopen('https://www.opengl.org/registry/api/GL/glcorearb.h')
    with open('include/GL/glcorearb.h', 'wb') as f:
        f.writelines(web.readlines())
else:
    print('Reusing glcorearb.h from include/GL...')

by

import ssl
# stuff
# ...

# Download glcorearb.h
if not os.path.exists('include/GL/glcorearb.h'):
    print('Downloading glcorearb.h to include/GL...')
    context = ssl._create_unverified_context()
    web = urllib2.urlopen('https://www.opengl.org/registry/api/GL/glcorearb.h', context=context)
    with open('include/GL/glcorearb.h', 'wb') as f:
        f.writelines(web.readlines())
else:
    print('Reusing glcorearb.h from include/GL...')

and got it running perfectly

What it says on the tin.

They've changed gl3.h to glcorearb.h, located here: http://www.opengl.org/registry/api/glcorearb.h

I've tried modifying gl3w to output C++ instead of C code (mostly adding namespaces), and it seems to work for my purposes. Is this something that would be merged upstream? Would you prefer the existing gl3w_gen.py script to output both versions (i.e. gl3w.c and gl3w.cc), or have a separate generator script for C and C++? Would you rather I fork and create a separate repository for the C++ version?

ISO C forbids casting between void* and any function pointer, since it assumes (for portabilities sake), they can have different widths.
Therefore, compilers will spit out an ugly warning for code casting the result of dlsym to a function pointer.

The standard way of solving this is to replace the simple cast to function pointer, with a rather clumsy cast like this:

/* before: */
if (!res)
    res = (GL3WglProc) dlsym(libgl, proc);

/* after: */
if (!res)
    *(void **)(&res) = dlsym(libgl, proc);

Looks dangerous, but confirms to both ISO C and POSIX. Since POSIX.1-2013 every confirming implementation has to support casting between void* and function pointers. Nevertheless, most compilers still spit out a warning.

I've done this on my local fork, and can confirm it's working if compiled as C. No clue how a C++ compiler will react to this, though.

I can't generate gl3w in vs2017. And the gl3w generate by py script made some mistakes in my source code .

For those of us who have to write code on MS Windows, it's often more convenient to have the GL command loader be all you need without relying on a system <GL/glcorearb.h>.

Attached is a modified version of gl3w_gen that adds the necessary typedefs and #defines to gl3w.h. (Plus some unnecessary commenting and replacement of tabs by spaces.) Hope it is useful, either to merge bits of code into gl3w_gen or distribute as a separate program.

gl3w_gencomplete.py.txt

When integrating the gl3w project into bigger projects it would be preferable to disable every optional code to reduce build time a bit and to remove clutter from the project dir.

I wanted to switch over to this, but I have one issue: there is no definition of GL_COMPRESSED_RGBA_S3TC_DXT1_EXT or similar. Is this by design? I see there is other compression formats like BPTC and ASTC, but no DXT.

May I suggest creating a separate repository to publish prebuilt gl3w.c/.h ?
Running Python is an additional step that is pretty much in the way for most people willing to use the resulting output (especially for Windows users). And it'd be nice to have versioned updates of gl3w.c following updates of glcorearb.h

Thanks a lot!

It is line 80

in function static void *get_proc(const char *proc)

res = glXGetProcAddress((const GLubyte *) proc); <-- this causes error

replacing with
res = (void *)glXGetProcAddress((const GLubyte *) proc);
solves the problem

I use g++ though, maybe other compilers think it is fine and let it go

System information:
VMWare Player with 3D Acceleration
Manjaro Linux as Guest OS, Windows 10 as Host OS (GTX 1660 Ti GPU)
glxinfo in guest OS:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 3.3
    Max compat profile version: 3.3
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.0.7
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.3 (Compatibility Profile) Mesa 20.0.7
OpenGL shading language version string: 3.30
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.0.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

Using gl3wIsSupported(3, 3) returns 0. However, OpenGL 3.3 works fine, and I am able to create an OpenGL 3.3 context with GLFW and use the functions provided by gl3w to render to it.

Hi! I'm having trouble understanding how to use this function. Can you put an example of how to use it in the README please?

Thank you!

Hello there !

I don't know if it's just me not using this lib correctly, but I have a small "problem": in one of my project, I'm using gl3w_gen.py to generate gl3w.c, which I then compile as a static lib. The problem comes from the downloaded glcorearb.h file, which includes KHR/khrplatform.h (line 616 as of today) : this header is nowhere to be found on my systems (I'm developing on both Linux (Mint 18.3, which is derived from a recent Ubuntu I think) and Windows 10)

Fortunately for me I have another lib in my project which does include khrplatform.h so I fixed my problem by adding the correct include directory to the gl3w lib. But I find it odd that gl3w would generate a file which doesn't compile out of the box.

Since I can't seem to find any pertinent information on the subject, I'm starting to think that maybe I'm doing something wrong ? Am I the only one having this issue ? Would it make sense to slightly modify gl3w_gen.py to also download this file (found here : https://www.khronos.org/registry/EGL/api/KHR/khrplatform.h) so that it would build out of the box ?

Regards,
Damien

The Readme file fails to mention that the python script can take a --ext flag that lets you use GL extension through gl3w.

Hi there,

I've been recently testing out gl3w and I was trying to compile&run provided examples.
While compiling the test.c which uses glut worked correctly, the glfw_test.c results in a segfault.
I've tried to track the issue with gdb and the code seems to be failing in parse_version function, specifically a call to glGetIntegerv, complaining about unknown type.

I was wondering if someone else has encountered such issue?
I am running a mac os 10.11.6, and my compilation command is:

clang -framework Cocoa -framework IOKit -framework OpenGL src/glfw_test.c src/gl3w.c -Iinclude -lglfw3 -ldl -ggdb -o test_gl3w

Thanks!

For now, we have to add gl3w.c into the project as a source file. It is annoying sometimes if we have many an OpenGL projects to create because we have to repeat this adding work for each new project and the compiler has to compile it again and again, generating exactly the same binary code which resides in every executible. GLEW, on the other hand, is a library available by default in Ubuntu. All we need to do to load OpenGL functions is add a linking flag for it. Then all the functions in GLEW are ready to use. Further, only one copy of memory and file system space is consumed for GLEW. Is this the case for gl3w? That is, is gl3w available as a (shared) library in Ubuntu by default?

The README.rst file claims that Python 2.x is required, while the wiki correctly claims that version 2.6 is the minimum version required.

Using Python 2.5 yields this error:
gl3w_gen.py:16: Warning: 'with' will become a reserved keyword in Python 2.6