DerelictGL3 `glCreateShader` Access Violation

Question

Introduction

I am attempting to create an OpenGL shader in D using Derelict's OpenGL binding. During the making of a quick test application to see if I could put everything together, it worked just fine, but when I started organizing things slightly better I have run into a highly odd (in terms of my understanding of the D language and the bindings) errror. Hopefully, I am simply being foolish.

If I were to call glCreateShader(GL_VERTEX_SHADER) in the module spacegame.game.game:

module spacegame.game.game;

import lib.window.stage;

import derelict.opengl;
import derelict.opengl.types;

mixin glFreeFuncs!(GLVersion.gl45);

/**
 * The game stage.
 */
class Game : Stage
{
    this ()
    {
        super();

        glCreateShader(GL_VERTEX_SHADER);
    }
}

It works just fine! There are no errors at all. On the other hand, if I were to import module lib.render.shaderprogram from the module above:

module lib.render.shaderprogram;

import std.stdio;

import derelict.opengl;
import derelict.opengl.types;

mixin glFreeFuncs!(GLVersion.gl45);

void makeShader ()
{
    glCreateShader(GL_VERTEX_SHADER);

    writeln("I never output!");
}

And call the makeShader function from the constructor where I called glCreateShader before (whereas it worked), I get the following error:

object.Error@(0): Access Violation

As far as I am aware, everything is the same, including the imports, right? As the shaderprogram module is only imported from the game module, the GL context will already have been set up, as in the first example.

What I cannot seem to understand is why the first example would work, whilst the second does not.

Is there some D language compiler magic I am not aware of here? Any pointers in the right direction would be highly appreciated.

Moreover

In the "quick test application" I mentioned before, I had no problem whatsoever rendering a simple triangle to a GLFW window. And rendering does work if I create the shader program inside the Game class described in the first example.

For separation, however, it would definitely be better if shader program creation could be separated out. ;-)

Edit: @RichardAndrewCattermole suggested I would verify that the pointer to glCreateShader is not null in the second example. It is. That would explain why the error occurs. As to why it is indeed null surprises me, considering the imports are the same in both cases (including the mixin).

Answer 1

As @RichardAndrewCattermole pointed out, I was creating X copies of the same thing in multiple places, which beyond reasonable doubt confused the Derelict GL3 package. And actually, according to the official documentation of Derelict, it does state that you should wrap the implementation using glFreeFuncs into its own file, so that you can require that whenever necessary.

Doing so eliminated the null pointer.

This means that whenever the need to use the library arises, a simple import gl; like so is all that's required.