November 22, 2004 Re: extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | >
>Since it currently has "Win32" and "linux" hardcoded,
>it won't compile on platforms other than those two...
>
>Neither dool nor DUI compiles.
>(bug reports on SourceForge)
thank you, I didn't notice that until now.
I'll try to change the version statments.
I'll let you know when (I believe) it's ready to try again.
Ant
|
November 23, 2004 [Help] extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | ok, here is what I have: on the libs opengl32 and glu32 found on windows\system32. - if I use extern(C) on gl.d and glu.d (from gl.h and glu.h) programs crash with "Acess Violation" UNLESS the -g flag is used - if I use extern(Windows) I get : testGL\TestGL.obj(TestGL) Error 42: Symbol Undefined _glFlush@0 testGL\TestGL.obj(TestGL) Error 42: Symbol Undefined _glLightfv@12 testGL\TestGL.obj(TestGL) Error 42: Symbol Undefined _glLightModelfv@8 testGL\TestGL.obj(TestGL) Error 42: Symbol Undefined _glEnable@4 testGL\TestGL.obj(TestGL) Error 42: Symbol Undefined _glMaterialf@12 testGL\TestGL.obj(TestGL) Error 42: Symbol Undefined _glPopMatrix@0 testGL\TestGL.obj(TestGL) Error 42: Symbol Undefined _glClearColor@16 testGL\TestGL.obj(TestGL) (more...) So, seems I messed up somewhere else... where? I created the import libs with implib: \DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\opengl32.lib C:\WINNT\system32\opengl32.dll \DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\glu32.lib C:\WINNT\system32\glu32.dll Ant |
November 23, 2004 Re: [Help] extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | In article <cnui5s$2c3i$1@digitaldaemon.com>, Ant says... > >ok, here is what I have: > >on the libs opengl32 and glu32 found on windows\system32. > >- if I use extern(C) on gl.d and glu.d (from gl.h and glu.h) > programs crash with "Acess Violation" UNLESS the -g flag is used >- if I use extern(Windows) > I get : >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glFlush@0 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glLightfv@12 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glLightModelfv@8 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glEnable@4 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glMaterialf@12 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glPopMatrix@0 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glClearColor@16 >testGL\TestGL.obj(TestGL) >(more...) > >So, seems I messed up somewhere else... where? > >I created the import libs with implib: >\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\opengl32.lib C:\WINNT\system32\opengl32.dll >\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\glu32.lib C:\WINNT\system32\glu32.dll > >Ant Ant, This is the an old problem with digitalmars' implib tool. It is unable to make usable import link libraries from the system dll's (specifically, it doesn't know how to append the @# symbols to each function; this postfix describes the total size in bytes of each functions parameter list). This postfix is required by digitalmars compilers to describe exported functions of the WINAPI type (thus the need for extern(Windows) for opengl symbols). What a few of us have finally found out is that you must make a "def" file to get the symbols "mapped" appropriately. There have been several discussions about this over at dsource.org. Because this problem with opengl32 libs was cropping up so often amongst newcomers to D on windows, I finally commited some *.def files to subversion within the win32 Bindings project. I must say that I've really come to appreciate how wonderfully simple Linux is in comparison to windows (when it comes to linking libraries with your programs). The opengl32.def and glu32.def files are used exactly the same as the opengl32.lib and glu32.lib implibs; that is, you link them with the d object file as if they were a link library. They allow your program to link properly to the dll's (in fact you could make the actual implibs out of them if you want, but it's not necessary). Download them here: http://svn.dsource.org/svn/projects/bindings/trunk/def/ Place them in one of your dm\lib or dmd\lib directories and link them in along with the other libs used by your program. All undefined symbols should be eliminated. Tell me how it works. Later, John |
November 23, 2004 Re: [Help] extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | And just to clarify, I have succeeded in getting DUI's opengl working with windows (using XP). All DUI Opengl test programs compile and run fine now. :-) In article <cnui5s$2c3i$1@digitaldaemon.com>, Ant says... > >ok, here is what I have: > >on the libs opengl32 and glu32 found on windows\system32. > >- if I use extern(C) on gl.d and glu.d (from gl.h and glu.h) > programs crash with "Acess Violation" UNLESS the -g flag is used >- if I use extern(Windows) > I get : >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glFlush@0 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glLightfv@12 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glLightModelfv@8 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glEnable@4 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glMaterialf@12 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glPopMatrix@0 >testGL\TestGL.obj(TestGL) > Error 42: Symbol Undefined _glClearColor@16 >testGL\TestGL.obj(TestGL) >(more...) > >So, seems I messed up somewhere else... where? > >I created the import libs with implib: >\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\opengl32.lib C:\WINNT\system32\opengl32.dll >\DD\usr\bin\implib /noi /system \DD\dantfw\GTK\lib\glu32.lib C:\WINNT\system32\glu32.dll > >Ant |
November 23, 2004 Re: extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | Ant wrote:
>>Since it currently has "Win32" and "linux" hardcoded,
>>it won't compile on platforms other than those two...
>>
>>Neither dool nor DUI compiles.
>>(bug reports on SourceForge)
>
> My fault! :(
> what should I do? just use "else" instead of linux?
Yes, you could start by doing that and any real linux
dependencies could be found further down the road...
It was covered in another thread, but version(Unix) is broken
Aiming for the regular C library / POSIX stuff is usually good
SourceForge has Mac OS X in their compile farm, I think ?
--anders
|
November 23, 2004 Re: [Help] extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | On Tue, 23 Nov 2004 09:28:19 +0000, John Reimer wrote: > This is the an old problem with digitalmars' implib tool. It is unable to make usable import link libraries from the system dll's > > http://svn.dsource.org/svn/projects/bindings/trunk/def/ > thank you, I'll try that later tonight. Ant |
November 23, 2004 Re: extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | In article <cnv7fn$ess$1@digitaldaemon.com>, > >SourceForge has Mac OS X in their compile farm, I think ? I don't think I have the time or the will to learn how to use it. Would you try it if I changed it? Well, I'll change it anyway. Ant |
November 24, 2004 Re: extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | "Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.11.21.23.07.12.189217@yahoo.ca... > John Reimer found that > > replacing extern(C) with extern(Windows) on the > DUI OpenGL extension decalrations fixes all the problems > with the OpenGL on DUI. Hmm. This sounds like it could be the cause of the crashing problem you were having when not using -g. Not using -g sets up a slightly different stack frame with different cleanup algorithms. |
November 24, 2004 Re: [Help] extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | John Reimer wrote: > This is the an old problem with digitalmars' implib tool. It is unable to make > usable import link libraries from the system dll's > What a few of us have finally found out is that you must make a "def" file to > get the symbols "mapped" appropriately. > Download them here: > > http://svn.dsource.org/svn/projects/bindings/trunk/def/ > > Place them in one of your dm\lib or dmd\lib directories and link them in along > with the other libs used by your program. All undefined symbols should be > eliminated. Tell me how it works. seems that doesn't work with link.exe. " \dantfw\GTK\lib\opengl32.def Error 43: Not a Valid Library File " I always compile and link in to steps. Is it possible to make work with link.exe ? Ant |
November 24, 2004 Re: [Help] extern(C) / extern(Windows) - DUI OpenGL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | In article <co0o3v$2lt5$1@digitaldaemon.com>, Ant says... > >John Reimer wrote: > >> This is the an old problem with digitalmars' implib tool. It is unable to make usable import link libraries from the system dll's > > >> What a few of us have finally found out is that you must make a "def" file to >> get the symbols "mapped" appropriately. >> Download them here: >> >> http://svn.dsource.org/svn/projects/bindings/trunk/def/ >> >> Place them in one of your dm\lib or dmd\lib directories and link them in along with the other libs used by your program. All undefined symbols should be eliminated. Tell me how it works. > >seems that doesn't work with link.exe. >" >\dantfw\GTK\lib\opengl32.def > Error 43: Not a Valid Library File >" >I always compile and link in to steps. >Is it possible to make work with link.exe ? > >Ant Sorry, Ant, I assumed the linker would accept it the same way, but I guess it works only with the dm and dmd compiler command line. To convert the "def" files to import libraries do: implib glu32.lib glu32.def implib opengl32.lib opengl32.def where implib is the digitalmars one and the *.lib are the resulting import libraries. I hope that does it. I think I'll upload the two libraries to the Bindings project so that people won't have to convert it themselves in the future. Later, John |
Copyright © 1999-2021 by the D Language Foundation