Ooops! That’s Not a Feature!

In a recent post, I described a problem with DMD 1.018 and Derelict. I assumed it was a bug with the new compiler. As it turns out, the old behavior was a bug and the compiler is now working as intended. It’s not a big deal for me, as the workaround isn’t too painful. I’ll be able to get Derelict patched up in due course and users of the library will be able to use Derelict with 1.018 and all future versions of DMD. Though, the fix I’m considering makes use of string mixins, so it won’t work with pre-CTFE versions of DMD. Though I might use template mixins instead. We’ll see.

Unfortunately, this issue goes beyond Derelict. There are several OpenGL bindings out there that are affected by this. If you are using one of them and have not yet upgraded your compiler, you will be in for a bit of a shock when you do. Here’s a list of the bindings I know of that use the same, no-longer-legal technique:

Bindings – both the gl and glu modules are affected

D-porting – both opengl.d and openglu.d, found in the opengl.zip file, are affected

GLFW – three modules (in support/d/imports in the directory tree) are affected: gl.d, glu.d and glfw.d

If you are using any of the above modules, you will have to update them (or ask a maintainer to) to use them with DMD 1.018 and later. The old OpenGL binding at DedicateD is not affected, as it is not cross-platform (and is actually quite outdated by now, anyway).

There may be other D modules out there, bindings to libraries other than OpenGL or perhaps OpenGL bindings I’m unaware of, that are affected. If you find yourself using one of them, the offending code looks like, or similar to, this:

version(Windows)
{
    extern(Windows):
}
else
{
    extern(C):
}

// function, or function pointer, declarations follow here

Walter outlines some alternative solutions in a newsgroup post. Choose an option that works for you and roll with it.

Technorati Tags: D Programming Language, DMD, Digital Mars, Derelict, OpenGL bindings