Problems with OpenGL bindings and D2

[Sergey Gromov]

Simen Kjaeraas <simen.kjaras at gmail.com> wrote:
> On Wed, 17 Sep 2008 01:02:59 +0200, Bill Baxter <wbaxter at gmail.com> wrote:
> 
> > I believe the scoping was changed so that the extern(): block  no
> > longer continued to the end of file.  The fix added to make everyones
> > programs compile again was "extern(System):" which can be used without
> > a version block, and basically acts like "extern(Windows):" on windows
> > and "extern(C):" everywhere else.
> >
> > --bb
> 
> Thanks, but that don't seem to fix my problem. However, you might be onto  
> something, as the name mangling seems wrong. _glClear should be _glClear at 4  
> and so on. A quick search tells me the first is __cdecl and the latter  
> __stdcall.
> Moving the declarations from gl/gl.d to my source file fixed all problems.  
> Bug?

Maybe it's the same problem I've had hit recently.

The names in DLL exports are not mangled according to the calling 
convention rules.  I.e. kernel32.dll exports CreateFileA although it's 
_CreateFileA at 28 in Microsoft's kernel32.lib.  The latter is a correctly 
mangled name, the former is merely a symbolic reference.

There are two options for generating the correct import library, safe 
one, and flexible one.

The safe method is available if you have a COFF (MS-compatible) import 
library for your DLL.  Then you use
http://www.digitalmars.com/ctg/coffimplib.html
to convert it into an OMF import library usable with DMD.  Then simply 
use whatever export() generates the right names for your lib.

The flexible method is to use
http://www.dprogramming.com/linkdef.php
to create an import library based upon the linker errors produced by 
DMD.  Beware though that it's your responsibility to choose the correct 
extern() calling convention.  DLL does not have any calling convention 
meta-data, so linkdef will link any undefined symbols to the similarly 
named symbols in a DLL without any compatibility guarantee.