Ok, here is my installing feedback about the "HOpenGL-1.01 compatibility release pack for GHC-5.02": ** 1 ** Besides the following thing appears in the "configure" step: checking for GL/glut.h... yes and besides the glut.h directory IS in my cygwin.bat PATH, I got a very boring error during the "make" step: C:\WINDOWS\TEMP\ghc-476717.hc:4: GL/glut.h: No such file or directory The solution I used was replacing all "-#include <GL/glut.h>" by the absolute path of glut.h (in my case, "-#include <c:/usr/include/GL/glut.h>") in the HOpenGL files. That worked fine, but why did it happen? ** 2 ** During the "make" step, I got a LOT of warnings like: * Warning: Defined but not used: [...] * C:\WINDOWS\TEMP\ghc-432219.hc:71: warning: assignment discards qualifiers from pointer target type * Warning: Module `GL_VertexSpec' is imported, but nothing from it is used But I guess this happens because this is a "compatibility release", am I right? ** 3 ** After all the compilation process, when I tryied to run "hello.exe", I got the following messages in cygwin: opengl.dll not found (this appeared in a pop-up window) BASH.EXE: ./hello: Permission denied (in the cygwin shell) Trying to run the same example in the Windows Explorer, I got: glut.dll not found (pop-up window) I remember I needed to copy glut.dll to my "redboot_HS" in HOpenGL-1.00, so I did this. Then (still in Windows Explorer) I got: opengl.dll not found (pop-up window) I have the file opengl32.dll, but I needed to search opengl.dll in the web. I was surprised by this, because the opengl.org tech support (www.opengl.org/developers/faqs/technical/mswindows.htm) says that: "Unless there's an absolutely compelling reason ... I really would suggest using opengl32.dll, and letting the old opengl.dll thing die. opengl.dll comes from the now totally unsupported OpenGL for Windows release of OpenGL for Microsoft Windows by SGI. We stopped supporting that release over two years -- like no one ever touches the code." Ok, I found opengl.dll in http://tigger.uic.edu/~jayvee/opengl/opengldlls.zip and placed it in the redbook_HS folder. Unfortunately, the examples did not run... a very weird window was opened and the expected program didn't appear. I restarted my computer then and, when I tryied to run the examples again, I got a illegal operation (HELLO caused a invalid page fault in module WINMM.DLL in 0167:bfdf6633) *** I remember I had this problem no.3 in HOpenGL-1.00 too, but I don't remember how I solved it... It seems to me it's related with opengl.dll/opengl32.dll. Suggestions? -- Andre
[ Sigbjorn, Reuben: I've put you onto the CC: because you seem to be the WinDoze grandmasters for some fptools stuff... :-] Andre W B Furtado wrote:
Ok, here is my installing feedback about the "HOpenGL-1.01 compatibility release pack for GHC-5.02":
Thanks for the quick feedback! I tried it yesterday under cygwin, too. The first problem I've encountered is GreenCard versionitis: The InstallShield version available via http://haskell.org/greencard/ is quite old and broken beyond a point which autoconf could detect and fix. So the first step was to compile GreenCard from source, but again, some helping hand was required to build from the source tar ball with ghc-5.02: rm src/{Pretty,FiniteMap,GetOpt}.lhs make HC="ghc -package lang" Sigbjorn: Could you please update the InstallShield version to the latest sources?
[...] C:\WINDOWS\TEMP\ghc-476717.hc:4: GL/glut.h: No such file or directory
The solution I used was replacing all "-#include <GL/glut.h>" by the absolute path of glut.h (in my case, "-#include <c:/usr/include/GL/glut.h>") in the HOpenGL files. That worked fine, but why did it happen?
*sigh* ghc-5.02 comes with mingw, which is fine, but alas, mingw's headers are not complete: The PATH_TO_5.02\include\mingw\GL subdirectory is missing, although the corresponding libs are there. You can fix that by copying cygwin's /usr/include/GL subdirectory. Reuben (or whoever is in charge of the WinDoze versions of GHC): Could you please fix that in the upcoming InstallShield versions?
During the "make" step, I got a LOT of warnings like:
* Warning: Defined but not used: [...]
This is caused by GreenCard's inability to specify which (un)marshaling function is not needed => harmless.
* C:\WINDOWS\TEMP\ghc-432219.hc:71: warning: assignment discards qualifiers from pointer target type [...]
This is caused by the FFI's inability to specify which pointers are const. Some proposals were already made on the FFI list, but IIRC there was no consensus (which is a pity BTW! We should sometimes be a little bit more pragmatic there...). Again, this is harmless, at least for language bindings which rely on C. With C++, the corresponding function/method would not be found due to name mangling. (<= *hint* to the FFI people :-)
After all the compilation process, when I tryied to run "hello.exe", I got the following messages in cygwin:
Hmmm, I'm a bit surprised that you came that far. I had to inline some GLU constants in GLU_Quadrics, GLU_NURBS, and GLU_Tess, because of GLU versionitis. >:-( Perhaps another cygwin version? I've downloaded mine a few days ago. Strange. I'll have to do something about that...
[ DLL hell deleted ]
What linker options did your configure run determine? The only thing I had to do was to copy cygwin's /usr/bin/glut32.dll where your exe would find it. e.g. in the corresponding examples dir or windows\system. This is not surprising after all, because WinDoze doesn't come with GLUT. opengl32/glu32 vs. opengl/glu is a different story: You should always link against the more recent *32 versions, otherwise you probably won't get any hardware acceleration at all. Perhaps you should send me configure's log. BTW, if you don't have the *32 stuff, the self-extracting ZIP at ftp://ftp.microsoft.com/softlib/mslfiles/opengl95.exe is the way to go... Cheers, S.
Hi all, I've just been compiled ghc-5.02 with cygwin on win2k, but when I try to run some example the file opengl.dll is required. i downloaded oppengl.exe (link bellow), but there are a file called opengl95.dll. It does not work. Can Someone help me in order to run the examples? thanks a lot, Edson. On Tue, 30 Oct 2001, Sven Panne wrote:
[ Sigbjorn, Reuben: I've put you onto the CC: because you seem to be the WinDoze grandmasters for some fptools stuff... :-]
Andre W B Furtado wrote:
Ok, here is my installing feedback about the "HOpenGL-1.01 compatibility release pack for GHC-5.02":
Thanks for the quick feedback! I tried it yesterday under cygwin, too. The first problem I've encountered is GreenCard versionitis: The InstallShield version available via http://haskell.org/greencard/ is quite old and broken beyond a point which autoconf could detect and fix. So the first step was to compile GreenCard from source, but again, some helping hand was required to build from the source tar ball with ghc-5.02:
rm src/{Pretty,FiniteMap,GetOpt}.lhs make HC="ghc -package lang"
Sigbjorn: Could you please update the InstallShield version to the latest sources?
[...] C:\WINDOWS\TEMP\ghc-476717.hc:4: GL/glut.h: No such file or directory
The solution I used was replacing all "-#include <GL/glut.h>" by the absolute path of glut.h (in my case, "-#include <c:/usr/include/GL/glut.h>") in the HOpenGL files. That worked fine, but why did it happen?
*sigh* ghc-5.02 comes with mingw, which is fine, but alas, mingw's headers are not complete: The PATH_TO_5.02\include\mingw\GL subdirectory is missing, although the corresponding libs are there. You can fix that by copying cygwin's /usr/include/GL subdirectory.
Reuben (or whoever is in charge of the WinDoze versions of GHC): Could you please fix that in the upcoming InstallShield versions?
During the "make" step, I got a LOT of warnings like:
* Warning: Defined but not used: [...]
This is caused by GreenCard's inability to specify which (un)marshaling function is not needed => harmless.
* C:\WINDOWS\TEMP\ghc-432219.hc:71: warning: assignment discards qualifiers from pointer target type [...]
This is caused by the FFI's inability to specify which pointers are const. Some proposals were already made on the FFI list, but IIRC there was no consensus (which is a pity BTW! We should sometimes be a little bit more pragmatic there...). Again, this is harmless, at least for language bindings which rely on C. With C++, the corresponding function/method would not be found due to name mangling. (<= *hint* to the FFI people :-)
After all the compilation process, when I tryied to run "hello.exe", I got the following messages in cygwin:
Hmmm, I'm a bit surprised that you came that far. I had to inline some GLU constants in GLU_Quadrics, GLU_NURBS, and GLU_Tess, because of GLU versionitis. >:-( Perhaps another cygwin version? I've downloaded mine a few days ago. Strange. I'll have to do something about that...
[ DLL hell deleted ]
What linker options did your configure run determine? The only thing I had to do was to copy cygwin's /usr/bin/glut32.dll where your exe would find it. e.g. in the corresponding examples dir or windows\system. This is not surprising after all, because WinDoze doesn't come with GLUT.
opengl32/glu32 vs. opengl/glu is a different story: You should always link against the more recent *32 versions, otherwise you probably won't get any hardware acceleration at all. Perhaps you should send me configure's log. BTW, if you don't have the *32 stuff, the self-extracting ZIP at
ftp://ftp.microsoft.com/softlib/mslfiles/opengl95.exe
is the way to go...
Cheers, S.
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl
My cygwin is really old... I got it one year ago. BTW, does anyone know why the following thing appears when I use the "version" command in cygwin? The: not found The: not found
You can fix that by copying cygwin's /usr/include/GL subdirectory.
You mean, copy /usr/include/GL to PATH_TO_5.02\include\mingw\GL ?
You should always link against the more recent *32 versions
How can I do this? Although I do have the *32 stuff, the examples in redbook_hs request for the other (old) stuff... (this is Edson's problem also). I am sending my configure log attached (configure.txt). -- Andre ----- Original Message ----- From: Edson <jeaf@cin.ufpe.br> To: <hopengl@haskell.org> Sent: Tuesday, October 30, 2001 8:04 PM Subject: Re: [HOpenGL] HOpenGL-1.01 Feedback
Hi all,
I've just been compiled ghc-5.02 with cygwin on win2k, but when I try to run some example the file opengl.dll is required. i downloaded oppengl.exe (link bellow), but there are a file called opengl95.dll. It does not work. Can Someone help me in order to run the examples?
thanks a lot, Edson.
On Tue, 30 Oct 2001, Sven Panne wrote:
[ Sigbjorn, Reuben: I've put you onto the CC: because you seem to be the WinDoze grandmasters for some fptools stuff... :-]
Andre W B Furtado wrote:
Ok, here is my installing feedback about the "HOpenGL-1.01 compatibility release pack for GHC-5.02":
Thanks for the quick feedback! I tried it yesterday under cygwin, too. The first problem I've encountered is GreenCard versionitis: The InstallShield version available via http://haskell.org/greencard/ is quite old and broken beyond a point which autoconf could detect and fix. So the first step was to compile GreenCard from source, but again, some helping hand was required to build from the source tar ball with ghc-5.02:
rm src/{Pretty,FiniteMap,GetOpt}.lhs make HC="ghc -package lang"
Sigbjorn: Could you please update the InstallShield version to the latest sources?
[...] C:\WINDOWS\TEMP\ghc-476717.hc:4: GL/glut.h: No such file or directory
The solution I used was replacing all "-#include <GL/glut.h>" by the absolute path of glut.h (in my case, "-#include <c:/usr/include/GL/glut.h>") in the HOpenGL files. That worked fine, but why did it happen?
*sigh* ghc-5.02 comes with mingw, which is fine, but alas, mingw's headers are not complete: The PATH_TO_5.02\include\mingw\GL subdirectory is missing, although the corresponding libs are there. You can fix that by copying cygwin's /usr/include/GL subdirectory.
Reuben (or whoever is in charge of the WinDoze versions of GHC): Could you please fix that in the upcoming InstallShield versions?
During the "make" step, I got a LOT of warnings like:
* Warning: Defined but not used: [...]
This is caused by GreenCard's inability to specify which (un)marshaling function is not needed => harmless.
* C:\WINDOWS\TEMP\ghc-432219.hc:71: warning: assignment discards qualifiers from pointer target type [...]
This is caused by the FFI's inability to specify which pointers are const. Some proposals were already made on the FFI list, but IIRC there was no consensus (which is a pity BTW! We should sometimes be a little bit more pragmatic there...). Again, this is harmless, at least for language bindings which rely on C. With C++, the corresponding function/method would not be found due to name mangling. (<= *hint* to the FFI people :-)
After all the compilation process, when I tryied to run "hello.exe", I got the following messages in cygwin:
Hmmm, I'm a bit surprised that you came that far. I had to inline some GLU constants in GLU_Quadrics, GLU_NURBS, and GLU_Tess, because of GLU versionitis. >:-( Perhaps another cygwin version? I've downloaded mine a few days ago. Strange. I'll have to do something about that...
[ DLL hell deleted ]
What linker options did your configure run determine? The only thing I had to do was to copy cygwin's /usr/bin/glut32.dll where your exe would find it. e.g. in the corresponding examples dir or windows\system. This is not surprising after all, because WinDoze doesn't come with GLUT.
opengl32/glu32 vs. opengl/glu is a different story: You should always link against the more recent *32 versions, otherwise you probably won't get any hardware acceleration at all. Perhaps you should send me configure's log. BTW, if you don't have the *32 stuff, the self-extracting ZIP at
ftp://ftp.microsoft.com/softlib/mslfiles/opengl95.exe
is the way to go...
Cheers, S.
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl
Andre W B Furtado wrote:
My cygwin is really old... I got it one year ago. [...]
I'd recommend re-installing a fresh cygwin, things seem to go much smoother now than they did with version B20.1, e.g. the cursor keys are now working in the bash window (one of the most annoying non-features then), more complete headers, etc.
You mean, copy /usr/include/GL to PATH_TO_5.02\include\mingw\GL ?
Exactly.
You should always link against the more recent *32 versions
How can I do this? Although I do have the *32 stuff, the examples in redbook_hs request for the other (old) stuff... (this is Edson's problem also).
I am sending my configure log attached (configure.txt).
Hmmm, strange... Although configure finds opengl32.dll and glu32.dll, the program wants opengl.dll at runtime. A closer look at your configure output show that glut.dll is found, not glut32.dll, perhaps this in turn wants opengl.dll/glu.dll. Did you copy cygwin's /usr/bin/glut32.dll into windows\system or something similar? And where did your glut.dll come from? Could you try to change line 386 in aclocal.m4 from SUP_SEARCH_LIBS([#include <GL/glut.h>], glutMainLoop, glut glut32, have_glut=yes, have_glut=no) into SUP_SEARCH_LIBS([#include <GL/glut.h>], glutMainLoop, glut32 glut, have_glut=yes, have_glut=no) (i.e. swapping the order in which the GLUT libs are tested), run autoconf and re-run configure then (after removing config.cache, of course :-}. As a last resort, have you tried http://www.glsetup.com/, a respectable initiative to un-break the OpenGL mess on most PCs? Cheers, S.
participants (3)
-
Andre W B Furtado -
Edson -
Sven Panne