Yann Morvan wrote:
[...] However the error seems to clearly come from the call to blendEquation, since the program runs fine when I comment it out.
From having a look at the binding, my guess is that the call to hOpenGL_getProcAddress returns a NULL pointer, the reason for that would be that a configuration problem with the opengl headers and libraries when I built the package is causing hOpenGL_gpa in HsOpenGL.c to behave oddly.
Hmmm, is any example requiring the OpenGL extension mechanism working for you, e.g. FogCoord, BlendEqn, MultiTex, Histogram, ...?
The thing is I am very confused as to how GHC configures itself when it comes to the OpenGL headers and libraries. Does it use the headers in usr/local/include/mingw or usr/include/w32api, does it use the libraries from lib/w32api, or usr/local/gcc-lib, or the windows dlls, or something else ?
Once I knew this, but I think I'll have to take a closer look at these things again before I can make any statement. :-]
[...] I guess a good start would be to -know what implementation of OpenGL works best with HOpenGL under windows
The OpenGL implementation should really not matter at all, the only issue I'm aware of is tessellation under any WinDoze: Microsoft's DLL only supports an ancient GLU version, so someday I'll have to find a workaround. It doesn't seem to be mission-critical for anybody so far, so I was simply too lazy fixing this.
-place the corresponding files where fptools will look when configuring the build, and prevent it from finding headers that don't match libraries and vis versa [...]
configure should take care of this, not you. Having the output of the configure run and the compilation log plus config.log might help. Cheers, S.