Problems with OpenGL bindings and D2

[Bill Baxter]

On Wed, Sep 17, 2008 at 11:37 PM, Sergey Gromov <snake.scaly at gmail.com> wrote:
> 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.
>

 If you have the DLL, I've always had success creating the DMD COFF
import library for it using "implib" in the basic utils package.
Usually you'll need to create it using the /system flag.  If that
doesn't work try it without the /system flag.

--bb