ANNOUNCE: HOpenGL 1.02 released
HOpenGL, a Haskell binding for OpenGL and GLUT version 1.02 I am pleased to announce the thirteenth release of the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the* industrial strength 3D graphics API and a GUI toolkit. More details about HOpenGL can be found at http://haskell.org/HOpenGL This is a mainly a compatibility release for >= GHC-5.x, including some minor extensions. What's new: * Added support for 3D textures: texImage3D, texSubImage3D, copyTexSubImage3D. * Added a "make install" target to add a HOpenGL package to GHC. This makes using HOpenGL much easier: A simple ghc -package HOpenGL --make MyCoolApp.hs is enough for most applications. * GLUT exports its own versions of System.exit{With,Failure} now to avoid GHC's problems of those functions if they were issued during callbacks. * Fixed quite a few library incompatibilities for GHC >= 5.02. * Fixed some minor GLU incompatibilities. * Fixed GLUT game mode exports, so you could actually use it now! :-} * Changed configure to detect the native (i.e. non-Mesa) OpenGL as the default. This is more conforming with the OpenGL ABI spec. * Re-animated --with-hc and --with-green-card configure flags. HOpenGL-1.02 has been tested on the following platforms: * ix86, SuSE Linux 7.3, Mesa 3.4.2, bleeding edge GHC from CVS * ix86, Windows 2000, Cygwin (DLL 1.3.10), NVIDIA DetonatorXP * drivers 28.32, GHC 5.02.3 and 5.03-20020204 * SPARC, Solaris 2.7, Mesa 4.0.2, GHC 5.02.3 It should work on any platform with a recent GHC, too. As always, feedback and/or patches are highly welcome. Have fun! Sven
I'm on Solaris 2.6, GHC 5.02.3. Thank you for good work! Some quick notes: 1. examples/redbook_HS/Clip dumps core :( 2. ghci -package HOpenGL doesn't work as shipped, but I've managed to make it work. First, ghci seems to need HOpenGL.o, not libHOpenGL.a. HOpenGL.o can be made with this command: ld -r -o HOpenGL.o */*.o in the lib directory. Second, I've moved libraries from extra_ld_opts section to extra_libraries section in HOpenGL.conf. Cheers, -- anatoli t. __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
[ Forwarded to cvs-ghc, too, because of the first bug ] anatoli wrote:
I'm on Solaris 2.6, GHC 5.02.3. Thank you for good work! Some quick notes:
1. examples/redbook_HS/Clip dumps core :(
A quick look with ddd revealed that GHC's RTS has a bug in alloca resp. allocaBytes: It must return a pointer with the *strictest* alignment, which is 8 bytes on SPARC for 64-bit integrals/floats. Currently, the returned pointer has only an alignment of 4 bytes. :-(
2. ghci -package HOpenGL doesn't work as shipped, but I've managed to make it work. First, ghci seems to need HOpenGL.o, not libHOpenGL.a. HOpenGL.o can be made with this command: ld -r -o HOpenGL.o */*.o in the lib directory.
Well, using HOpenGL with the current GLUT toolkit interactively doesn't make that much sense (mainLoop never returns). Anyway: With a newer ghc-pkg, the above ld stuff could be done automatically during the --add-package, IIRC, but I was reluctant to make the installation process (even more :-} fragile...
Second, I've moved libraries from extra_ld_opts section to extra_libraries section in HOpenGL.conf.
Hmmm, this doesn't work if there are options different from "-lfoo", which is the case at my site: Configure determines that the options "-L/usr/openwin/lib" and "-R/usr/openwin/lib" must be used here, too. Thanks for your encouraging report! :-) Cheers, S.
Sven Panne
A quick look with ddd revealed that GHC's RTS has a bug in alloca resp. allocaBytes: It must return a pointer with the *strictest* alignment, which is 8 bytes on SPARC for 64-bit integrals/floats. Currently, the returned pointer has only an alignment of 4 bytes. :-(
Thanks, will try to fix that in my installation.
Well, using HOpenGL with the current GLUT toolkit interactively doesn't make that much sense (mainLoop never returns). Anyway: With a newer ghc-pkg, the above ld stuff could be done automatically during the --add-package, IIRC, but I was reluctant to make the installation process (even more :-} fragile...
Well, ghci is useful in quick change-compile-test cycles, so I think it does make at least some sense. But I'm not sure ghc-pkg does what you say it does. In hslibs this is handled by this rule: $(GHCI_LIBRARY) :: $(LIBOBJS) ld -r -o $@ $(LIBOBJS) $(STUBOBJS)
Hmmm, this doesn't work if there are options different from "-lfoo", which is the case at my site: Configure determines that the options "-L/usr/openwin/lib" and "-R/usr/openwin/lib" must be used here, too.
Firstly, -L and -R should stay in extra_ld_opts. Secondly, it looks like GHCi bug. It should either search something else than just LD_LIBRARY_PATH for .so libraries, or stop complaining about unknown symbols in hs_libraries. In any case, this is for ghc people. In any case, batch mode ghc works with this configuration (libs in extra_libraries, -L and -R are in extra_ld_opts) and ghci works with it if everything is in LD_LIBRARY_PATH, so I guess it's the correct one. -- anatoli t. __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
participants (3)
-
anatoli -
Sven Panne -
Sven Panne