[HOpenGL] HOpenGL-1.01 Feedback

[Edson]

	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
>