[HOpenGL] Some quick feedback (was ANNOUNCE: HOpenGL 1.02 released)

[anatoli]

Sven Panne <Sven_Panne@BetaResearch.de> wrote:
> 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/