headers
Simon Peyton-Jones | 2 Jun 2003 10:04
Picon
Favicon
Gravatar

FW: ANNOUNCE: GHC version 6.0


-----Original Message-----
From: glasgow-haskell-bugs-admin <at> haskell.org
[mailto:glasgow-haskell-bugs-admin <at> haskell.org] On Behalf Of Ralf Hinze
Sent: 31 May 2003 14:35
To: glasgow-haskell-bugs <at> haskell.org
Subject: Re: ANNOUNCE: GHC version 6.0

> Compiling 6.0 from source fails with:
>
> ../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi -Iinclude
'-#include
> "HsOpenGL.h"' -cpp -I/usr/X11R6/include -DCALLCONV=ccall
> '-DGET_PROC_ADDRESS="glXGetProcAddressARB"' -package-name OpenGL -O
> -Rghc-timing  -package base -split-objs    -c
> Graphics/Rendering/OpenGL/GL/Extensions.hs -o
> Graphics/Rendering/OpenGL/GL/Extensions.o  -ohi
> Graphics/Rendering/OpenGL/GL/Extensions.hi
> Graphics/Rendering/OpenGL/GL/Extensions.hs:42: parse error on input
> `glXGetProcAddressARB' <<ghc: 3261568 bytes, 2 GCs, 20548/20548
avg/max
> bytes residency (1 samples), 5M in use, 0.00 INIT (0.00 elapsed), 0.01
MUT
> (0.09 elapsed), 0.01 GC (0.03 elapsed) :ghc>> make[2]: ***
> [Graphics/Rendering/OpenGL/GL/Extensions.o] Fehler 1
> make[1]: *** [all] Fehler 1
> make[1]: Leaving directory
> `/var/tmp/portage/ghc-6.0/work/stage2-build/libraries' make: ***
[build]
> Fehler 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sven Panne | 6 Jun 2003 23:58
Picon

Getting GLU entry points at runtime

Does anybody know if there is way to get the proc addresses for

    gluUnProject4
    gluBuild3DMipmaps

dynamically i.e. at runtime? They appeared in GLU 1.3, WinDoze comes
with GLU 1.2, and glXGetProcAddress seems to be agnostic about GLU
functions (probably wglGetProcAddress behaves similarly). So I'm a bit
stuck here...  :-(

Cheers,
    S.
Permalink | Reply | 1 comment |
headers
Carl R. Witty | 13 Jun 2003 19:15

Re: Getting GLU entry points at runtime

Sven Panne <Sven.Panne <at> informatik.uni-muenchen.de> writes:

> Does anybody know if there is way to get the proc addresses for
> 
>     gluUnProject4
>     gluBuild3DMipmaps
> 
> dynamically i.e. at runtime? They appeared in GLU 1.3, WinDoze comes
> with GLU 1.2, and glXGetProcAddress seems to be agnostic about GLU
> functions (probably wglGetProcAddress behaves similarly). So I'm a bit
> stuck here...  :-(

The GLU routines are not part of the vendor drivers; they are a
separate layer on top of OpenGL.  So, if the Windows version of GLU
does not export gluBuild3DMipmaps, I'm pretty sure that means there's
no implementation of that function at all.

Carl Witty
Permalink | Reply | 0 comments |
headers
Sven Panne | 29 Jun 2003 14:12
Picon

HOpenGL 1.04 + GHC 6.x

Due to some minor changes in the standard library module Foreign, compiling
HOpenGL 1.04 doesn't work out out of the box with GHC 6.x anymore:

    GL.hs:34:
        Conflicting exports for `rotate':
          `module GL_CoordTrans' exports `GL_CoordTrans.rotate' imported from GL_CoordTrans at GL.hs:78
          `module GL_Marshal' exports `Data.Bits.rotate' imported from GL_Marshal at GL.hs:120

But this can easily be fixed by the following patch:

--SNIP----SNIP----SNIP----SNIP----SNIP----SNIP----SNIP----SNIP----SNIP--
--- HOpenGL-1.04.orig/lib/GL_Marshal.hs	2002-12-29 22:38:00.000000000 +0100
+++ HOpenGL-1.04/lib/GL_Marshal.hs	2003-06-29 13:56:44.000000000 +0200
 <at>  <at>  -62,7 +62,7  <at>  <at> 
     module CString
  ) where

-import Foreign
+import Foreign hiding ( Bits(..) )
  import CString(CString, newCString, peekCString, withCString)

  ----------------------------------------------------------------------
--SNIP----SNIP----SNIP----SNIP----SNIP----SNIP----SNIP----SNIP----SNIP--

Thanks to Tim Rädisch for pointing this out.

Cheers,
    S.
Permalink | Reply | 0 comments |
headers
Sven Panne | 1 Jul 2003 13:17
Picon

Re: HOpenGL 1.04 and Mac OS X

[ redirecting to the HOpenGL mailing list, because this might be of
   general interest for Mac users ]

Kevin Fowler wrote:
 > I'm just writing to say that I downloaded & compiled HOpenGL 1.04 on
 > Mac OS X 10.2.6 using GHC 6.0.

Nice to hear! :-)

 > The changes to get it to compile using the X11 version of GLUT were
 > pretty minimal. Most of the demos work and those that don't fail
 > because the OpenGL support isn't there in X11.

Could you send your changes? Perhaps I can make an "ultra-last"
release of the HOpenGL-1.0x series if it is worthwhile. And which demos
fail exactly?

 > Getting it to work with the native ("Cocoa") GLUT included with Mac OS
 > involved a bit more work (specifying frameworks, different
 > headers---GLUT/glut.h mostly, linking against libobjc, etc.) The GLUT
 > and Redbook demos seem to work fine.

Again, the changes would be interesting. Wolfgang Thaller, who seems
to be "Mr. Mac" on this mailing list, has probably done something
similar, so it would be nice to hear from him about HOpenGL 1.04, too.

The interest in Macs seems to be growing since Apple ships a more
"mainstream" OS, but, alas, I don't have access to such a platform.
This means that I depend on other people to get/keep HOpenGL running
there. The current development for HOpenGL happens in the fptools
(Continue reading)

Permalink | Reply | 0 comments |

Gmane