[Haskell-cafe] Win32 Open GL / Glut Applications

[John Wicket]

Wow, what an interesting bunch of reads.  I still haven't tried the options
yet as I dont work with windows too much.  What was the consensus? on the
steps to follow.  I will try finding a freeglut dll and then changing the
name to opengl32.dll and see if that works.

On 9/23/07, Ronald Guida <ronguida at mindspring.com> wrote:
>
> Sven Panne wrote:
> > On Friday 21 September 2007 20:19, Ronald Guida wrote:
> >> John Wicket wrote:
> >>  > yea, that is probably what I need.  Can you post in a
> step-by-step way.
> >>
> >> Here is a set of instructions for what I had to do to get FreeGLUT
> >> working with GHCi [...].
> >
> > Oh dear, a long a sad story... :-(
>
> And frustrating too.  :-)
>
> >> [...]  Although I just don't understand why freeglut, the
> >> Haskell GLUT library, and GHCi won't work together in the first place.
> >
> > That statement is not correct, they *do* work together. The problem
> you are
> > experiencing is that the GLUT version used to build the GHC
> installer/binary
> > distro is obviously not freeglut, but "classic" GLUT. As long as you
> only
> > use "classic" GLUT features, this is OK. Things get really hairy when
> you
> > want to use freeglut-only features and still have a GHC installer/binary
> > distro which is guaranteed to run with "classic" GLUT as well (with
> > restricted features in the latter case, of course). To do this
> properly, the
> > GLUT package has to resolve freeglut-only API entries dynamically, but
> > glutGetProcAddress is not contained in lots of GLUT DLLs out in the wild
> > (it's in GLUT API version 5 plus freeglut). This is really a pity and
> a big
> > design flaw in GLUT IMHO, but there is not much one can do about
> that.The
> > only thing left is to load the GLUT/freeglut dynamic library,
> > well, "dynamically" and resolve the freeglut API entries by hand.
> Doing this
> > is not hard, but a little bit tricky to get right portably: Use
> dlopen/dlsym
> > on most *nices, LoadLibrary/GetProcAddress on Windoze, something else
> on Mac
> > OS, take care of possible leading underscores, etc. etc. I really
> wanted to
> > avoid doing this, but it looks like there is no way around it. Given the
> > current time frame for the GHC 6.8.1 release, I don't think that it is
> > feasible to get this into that release, because I would need feedback
> from
> > lots of platforms to be sure things work.
>
> In fact, when I compiled freeglut with MSVC, it compiled successfully
> "out of the box".  When I tried to use my new freeglut.dll with GHCi,
> I got linker errors all over the place and I eventually discovered
> that the problem involves leading underscores.
>
> >> [...] darcs-1.0.9
> >>   http://darcs.net/darcs-1.0.9.tar.gz [...]
> >
> > There are darcs binaries for Windows, so there is no need to build it
> and the
> > libraries it needs:
> >
> >
>
> http://wiki.darcs.net/DarcsWiki/CategoryBinaries#head-c7910dd98302946c671cf63cb62712589b392074
>
> Ooo, Thank you!  ;-)
>
> > Furthermore, darcs itself is not needed for what you want to do.
> >
> >> [...] Freeglut-2.4.0
> >>   http://freeglut.sourceforge.net/index.php#download [...]
> >
> > The freeglut project currently doesn't provide prebuilt binaries, so
> this is
> > hardly the GLUT package's fault. ;-) Furthermore, the official way to
> build
> > the project on Windows is via MSVC, and there are projects files for
> this.
> > Building a DLL via MinGW/MSYS would be nice, too, so perhaps you
> could post
> > your patches in the freeglut-developer mailing list. I think that
> there will
> > be a new freeglut release soon, perhaps I can push people to make at
> least a
> > simple ZIP file with the binaries for Windows available on the
> project pages.
> >
> >> GLUT-2.1.1
> >>   You need to use darcs to download GLUT-2.1.1.
> >> [...]
> >>        Locate the line start starts with "build-depends:" and remove
> >>        the dependencies "array" and "containers"
> >
> > Now you enter the great world of Cabal versionits and the Big Library
> Splitup
> > (tm). ;-) If you want to use a bleeding edge version of GLUT, you need a
> > bleeding edge version of GHC and the libraries coming with it. A
> released
> > version is available via hackage.haskell.org.
>
> Rumor: Version-itis and the big library splitup are going to break
> everyone's existing code!  :-O
>
> >>   [...] 6. Modify "GLUT-2.1.1/Graphics/UI/GLUT/Extensions.hs" as
> follows:
> >>
> >>        Look at the last two lines:
> >>
> >> foreign import ccall unsafe "hs_GLUT_getProcAddress"
> hs_GLUT_getProcAddress
> >>
> >>    :: CString -> IO (FunPtr a)
> >>
> >>        Change "hs_GLUT_getProcAddress" to "glutGetProcAddress"
> >>
> >>   7. Modify "GLUT-2.1.1/cbits/HsGLUT.c" as follows:
> >>
> >>        Look for "void* hs_GLUT_getProcAddress(char *procName)" and
> >>        remove the whole function.
> >
> > Huh? If you *really* compile against the freeglut header, these steps
> are
> > unnecessary. What is the reason for this change?
>
> The reason for this change is that I had reached the point where I had
> one remaining linker error.  I found that hs_GLUT_getProcAddress is a
> stub that calls the real glutGetProcAddress, and I figured out that
> this call to the real glutGetProcAddress was refusing to link.  I made
> the determination that (1) the stub is there to fix a broken
> glutGetProcAddress, and (2) mine isn't broken.  Therefore, instead of
> trying to find the cause of the linker error, I decided to avoid the
> error entirely by removing the stub and calling directly to the real
> thing.
>
> >> {...]
> >>   11. In GHC's directory, there is a file named "package.conf".  This
> >>       file contains one extremely long line.  You need to find an
> >>       editor that will let you insert some text into this line without
> >>       introducing any line breaks.  Emacs can do this.
> >>
> >>       You need to locate the text << pkgName = "GLUT" >> and then you
> >>       need to locate << hsLibraries = ["HSGLUT-2.1.1"] >> to the right
> >>       of there.  The very next thing to the right of "hsLibraries"
> >>       should be << extraLibraries = [] >>.  You need to change it to
> >>       << extraLibraries = ["freeglut"] >>.
> >
> > This is unnecessary if you install the freeglut DLL correctly. What
> is the
> > output of "ghc-pkg describe GLUT" before this modification?
>
> By this time, I have bypassed the correct installation of freeglut.
>
> >>   13. If you want to /compile/ with GHCi, then you'll need to copy the
> >>       freeglut.dll file into the same directory as your newly-compiled
> >>       program.exe file.  I haven't tried static linking yet; that
> >>       would require recompiling freeglut as a static library instead
> >>       of a DLL.
> >
> > The "traditional" way is to put the DLL as "glut32.dll" into your
> > WINDOWS/system32, just next to opengl32.dll. :-P I don't know what the
> > Vista-approved way of doing this is, and probably the freeglut
> project needs
> > an installer. Any volunteers?
>
> The issue here is DLL Hell.  I now have two versions of the freeglut
> DLL.  One of them came from MSVC and the other came from my hacking.
> Neither version can be substituted for the other.  Putting the DLL
> file into the same directory as the EXE file appears to guarantee that
> the EXE picks it up.  Static linking would avoid the problem entirely.
>
> I just wish GHCi would link with the MSVC version of the freeglut DLL.
>
> What I really wish for, are pre-compiled versions of each piece that
> work together and a fully automated installer that select all the
> right versions of everything and put all the right pieces in all the
> right places.
>
> The best part of all is this: I went through so much trouble trying to
> get freeglut, Haskell-GLUT, and GHCi to play together and run some
> examples, that once I finally got it working, I ended up deciding
> /not/ to look at graphics programming for a while.
>
> -- Ron
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070924/9fa4f485/attachment.htm