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