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/