[ ghc-Bugs-1275126 ] configure problems with openGL and openAL

Bugs item #1275126, was opened at 2005-08-28 12:47
Message generated for change (Comment added) made by kagy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1275126&group_id=8032

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build System
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure problems with openGL and openAL

Initial Comment:
I've been compiling the latest GHC snapshot
(6.4.1.20050827) from source and have encountered some
annoying problems with the configure script not being
as intelligent as it should be.  This is on a GNU/Linux
system running Debian unstable.  Initially I didn't
have the openGL GLU headers installed so I got a
compile error when the "glu.h" file wasn't found.  I
believe that since the GLU library was installed, the
configure script assumed that the GLU header file would
be there -- or else it didn't check.  Installing the
GLU header files fixed this.   Then I got a weird bug
while compiling the openAL support in GHC:

------------------------------------------------------------------------
==fptools== make all - --no-print-directory -r;
 in
/home/mvanier/lang/useful/haskell/ghc/ghc-6.4.1.20050827/libraries/OpenAL
------------------------------------------------------------------------
rm -f Sound/OpenAL/ALC/Context.o; if [ ! -d
Sound/OpenAL/ALC/Context_split ]; then mkdir Sound/OpenAL
/ALC/Context_split; else /usr/bin/find
Sound/OpenAL/ALC/Context_split -name '*.o' -print |
xargs rm -
f __rm_food; fi;   
../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi
-Iinclude '-#include "HsOpenAL.h"' -cpp -DCALLCON
V=ccall -ignore-package OpenAL -O -Rghc-timing
-fgenerics  -package base  -package OpenGL -fgenerics 
-split-objs    -c Sound/OpenAL/ALC/Context.hs -o
Sound/OpenAL/ALC/Context.o  -ohi Sound/OpenAL/ALC/Co
ntext.hi
/tmp/ghc27232.hc: In function 's33v_ret':
/tmp/ghc27232.hc:553: error: void value not ignored as
it ought to be
/tmp/ghc27232.hc: In function 's33y_ret':
/tmp/ghc27232.hc:595: error: void value not ignored as
it ought to be
<<ghc: 60654736 bytes, 14 GCs, 2844362/5655392 avg/max
bytes residency (3 samples), 18M in use, 0.00 
INIT (0.00 elapsed), 0.18 MUT (0.40 elapsed), 0.09 GC
(0.12 elapsed) :ghc>>
make[2]: *** [Sound/OpenAL/ALC/Context.o] Error 1
make[1]: *** [all] Error 1
make: *** [build] Error 1

As a result, I disabled openAL support.

Mike Vanier
mvanier@xxxxxxxxxxxxxx


----------------------------------------------------------------------

Comment By: Kevin Glynn (kagy)
Date: 2005-10-08 11:08

Message:
Logged In: YES 
user_id=37873

I can't see a way to reopen this bug report, but I think it
should be. I hit
the same problem with Debian unstable.

Kevin


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-08-29 23:53

Message:
Logged In: NO 

It's not a private setup; Debian has four packages: GL libs,
GL headers,
GLU libs, GLU headers. It's quite possible to install GL
stuff without
GLU. Surely it's not too much to check for glu.h as well as
gl.h.

-- Ross

----------------------------------------------------------------------

Comment By: Sven Panne (spanne)
Date: 2005-08-29 20:26

Message:
Logged In: YES 
user_id=50298

Regarding your GLU header problem: This will only happen if 
you have GL and GLU libraries installed and a GL header, but 
no GLU header. This is a rather obscure setup which I've never 
heard before: It is common that you either have a) no GL/GLU 
stuff at all (OpenGL ignorant system), b) only GL/GLU libraries 
(OpenGL *user* system), but no header c) GL/GLU libraries 
and headers (OpenGL *development* system).  To avoid 
making the autoconf magic even more tricky, I declare your 
setup to be buggy. :-) Seriously: I think the autotools stuff 
should handle common differences between platforms, but not 
each and every obscure private setup, otherwise things get 
unmaintainable. 
 
Regarding the OpenAL problem: This is due to changes in the 
OpenAL API itself, which are already handled in the HEAD. 
Furthermore, the OpenAL stuff in the STABLE branch is 
practically unusable, because it is very incomplete. If you want 
a working and complete OpenAL binding, you can use the 
HEAD. I'll make "no OpenAL" the default in STABLE... 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1275126&group_id=8032