Conflicts between extension function decls (I could just be dumb)

[JarrettBillingsley]

I admit I don't know too much about GL extensions, so I don't know which ones are ancient and shouldn't really be used anymore, buuuut I'm writing an OpenGL binding and I don't know what extensions the users of this binding will need. So I used Glad to generate a loader that loads all extensions (by leaving off the --extensions option).

The resulting (enormous) loader doesn't compile because it seems that there are a number of commands which are required by multiple extensions, so Glad generates multiple declarations for their function pointers. I've commented out the duplicates, and have found out roughly which ones stomp on each other. It's a big list.

GL_ARB_fragment_program/GL_ARB_vertex_program
    glBindProgramARB
    glDeleteProgramsARB
    glGenProgramsARB
    glGetProgramEnvParameterdvARB
    glGetProgramEnvParameterfvARB
    glGetProgramivARB
    glGetProgramLocalParameterdvARB
    glGetProgramLocalParameterfvARB
    glIsProgramARB
    glProgramEnvParameter4dARB
    glProgramEnvParameter4dvARB
    glProgramEnvParameter4fARB
    glProgramEnvParameter4fvARB
    glProgramLocalParameter4dARB
    glProgramLocalParameter4dvARB
    glProgramLocalParameter4fARB
    glProgramLocalParameter4fvARB
    glProgramStringARB
    glGetProgramStringARB

GL_ARB_vertex_program/GL_ARB_vertex_shader
    glDisableVertexAttribArrayARB
    glEnableVertexAttribArrayARB
    glGetVertexAttribdvARB
    glGetVertexAttribfvARB
    glGetVertexAttribivARB
    glGetVertexAttribPointervARB
    glVertexAttrib1dARB
    glVertexAttrib1dvARB
    glVertexAttrib1fARB
    glVertexAttrib1fvARB
    glVertexAttrib1sARB
    glVertexAttrib1svARB
    glVertexAttrib2dARB
    glVertexAttrib2dvARB
    glVertexAttrib2fARB
    glVertexAttrib2fvARB
    glVertexAttrib2sARB
    glVertexAttrib2svARB
    glVertexAttrib3dARB
    glVertexAttrib3dvARB
    glVertexAttrib3fARB
    glVertexAttrib3fvARB
    glVertexAttrib3sARB
    glVertexAttrib3svARB
    glVertexAttrib4bvARB
    glVertexAttrib4dARB
    glVertexAttrib4dvARB
    glVertexAttrib4fARB
    glVertexAttrib4fvARB
    glVertexAttrib4ivARB
    glVertexAttrib4NbvARB
    glVertexAttrib4NivARB
    glVertexAttrib4NsvARB
    glVertexAttrib4NubARB
    glVertexAttrib4NubvARB
    glVertexAttrib4NuivARB
    glVertexAttrib4NusvARB
    glVertexAttrib4sARB
    glVertexAttrib4svARB
    glVertexAttrib4ubvARB
    glVertexAttrib4uivARB
    glVertexAttrib4usvARB
    glVertexAttribPointerARB

GL_EXT_direct_state_access/GL_EXT_draw_buffers2
    glDisableIndexedEXT
    glEnableIndexedEXT
    glGetBooleanIndexedvEXT
    glGetIntegerIndexedvEXT
    glIsEnabledIndexedEXT

GL_EXT_texture_array/GL_NV_geometry_program4
    glFramebufferTextureLayerEXT

GL_NV_gpu_shader5/GL_AMD_gpu_shader_int64
    glGetUniformi64vNV
    glGetUniformui64vNV
    glProgramUniform1i64NV
    glProgramUniform1i64vNV
    glProgramUniform1ui64NV
    glProgramUniform1ui64vNV
    glProgramUniform2i64NV
    glProgramUniform2i64vNV
    glProgramUniform2ui64NV
    glProgramUniform2ui64vNV
    glProgramUniform3i64NV
    glProgramUniform3i64vNV
    glProgramUniform3ui64NV
    glProgramUniform3ui64vNV
    glProgramUniform4i64NV
    glProgramUniform4i64vNV
    glProgramUniform4ui64NV
    glProgramUniform4ui64vNV
    glUniform1i64NV
    glUniform1i64vNV
    glUniform1ui64NV
    glUniform1ui64vNV
    glUniform2i64NV
    glUniform2i64vNV
    glUniform2ui64NV
    glUniform2ui64vNV
    glUniform3i64NV
    glUniform3i64vNV
    glUniform3ui64NV
    glUniform3ui64vNV
    glUniform4i64NV
    glUniform4i64vNV
    glUniform4ui64NV
    glUniform4ui64vNV

GL_EXT_geometry_shader4/GL_EXT_separate_shader_objects (wait, but that's GLES2)
    glProgramParameteriEXT

GL_EXT_direct_state_access/GL_EXT_separate_shader_objects (again, GLES2)
    glProgramUniform1fEXT
    glProgramUniform1fvEXT
    glProgramUniform1iEXT
    glProgramUniform1ivEXT
    glProgramUniform2fEXT
    glProgramUniform2fvEXT
    glProgramUniform2iEXT
    glProgramUniform2ivEXT
    glProgramUniform3fEXT
    glProgramUniform3fvEXT
    glProgramUniform3iEXT
    glProgramUniform4fEXT
    glProgramUniform4fvEXT
    glProgramUniform4iEXT
    glProgramUniform4ivEXT
    glProgramUniformMatrix2fvEXT
    glProgramUniformMatrix3fvEXT
    glProgramUniformMatrix4fvEXT
    glProgramUniformMatrix2x3fvEXT
    glProgramUniformMatrix2x4fvEXT
    glProgramUniformMatrix3x2fvEXT
    glProgramUniformMatrix3x4fvEXT
    glProgramUniformMatrix4x2fvEXT
    glProgramUniformMatrix4x3fvEXT
    glProgramUniformMatrix4fvEXT
    glProgramUniform1uiEXT
    glProgramUniform1uivEXT
    glProgramUniform2uiEXT
    glProgramUniform2uivEXT
    glProgramUniform3ivEXT
    glProgramUniform3uiEXT
    glProgramUniform3uivEXT
    glProgramUniform4uiEXT
    glProgramUniform4uivEXT

I'm a little surprised by GL_EXT_separate_shader_objects conflicting because I generated this loader with just the GL profile, no GLES, so I don't know why the GLES2 bits of that extension are getting loaded. Maybe another bug?

[Dav1dde]

Thanks, I will take a look. I assume you're using it for the D programming language? Are you using the latest version I fixed a bug like that in the last commit.

[Dav1dde]

Can you give me some more information, I tried to reproduce this, but everything I try seems to compile, e.g.:

─[dav1d@archbox][~/workspaces/d/glad]╼ python2 main.py --out-path=./build --generator=d                                                                                          1 ↵  ✭master 
Using local spec: gl.xml
Generating gl bindings...
─[dav1d@archbox][~/workspaces/d/glad]╼ dmd -Ibuild build/glad/gl/* -L-ldl                                                                                                             ✭master 
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: Fehler: ld gab 1 als Ende-Status zurück
--- errorlevel 1

The last error message means, there is simply no main function, linking failed (expected), but compilation succeeded.

Can you give me the command you use to compile your code and the command which you used to generate the loader?

Thanks

[JarrettBillingsley]

Ah, sorry about that.

I'm using the C binding actually, but with one important distinction: I'm compiling the resulting .c file as C++ instead of C. Apparently C doesn't care that there are multiple definitions of these things, but C++ is more strict.

The loader generator command:

python main.py --profile=compatibility --out-path=testloader --api="gl=" --generator=c --spec=gl

Then I rename testloader/src/glad.c to glad.cpp, and compile:

gcc testloader/src/glad.cpp -I./testloader/include

[0x1100]

The three last extensions are also written against plain OpenGL, so there's nothing wrong about them getting loaded:
https://www.opengl.org/registry/specs/EXT/geometry_shader4.txt
https://www.opengl.org/registry/specs/EXT/separate_shader_objects.txt
https://www.opengl.org/registry/specs/EXT/direct_state_access.txt

Concerning the compilation error you encounter, this is not valid C++ code. (3.2 One definition rule)
However, this is valid C code since those are all tentative definitions. (6.9.2 External object definitions)
Glad supplies a C binding that requires a C compiler. I see no bug.

Why would you want to compile it with a C++ compiler?

[Dav1dde]

With latest commit, C++ should be supported. My small tests run through and @pyalot uses it in a bigger C++ project.

[Dav1dde]

Ok now it is really fixed, thanks everyone!