GHC 6.10 and OpenGL

newer
Moving the messages for compiler...

Paul L

22 Nov 2008 22 Nov '08

3:31 p.m.

Hi everyone, It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy. I'm not here to argue whether this decision by GHC dev team is right or wrong, but what's really causing the pain is that the OpenGL binding doesn't have its own binary installer for Windows, and compilation from source on this platform is non-trivial. I wouldn't recommend doing it for ordinary users. So my question is, are we going to see a binary installer for OpenGL binding provided separately from either HOpenGL site, or Hackage? Or even the GHC installation page? -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale

Show replies by date

Don Stewart

22 Nov 22 Nov

3:34 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

ninegua:

...

Hi everyone,

It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.

$ cabal install OpenGL

...

I'm not here to argue whether this decision by GHC dev team is right or wrong, but what's really causing the pain is that the OpenGL binding doesn't have its own binary installer for Windows, and compilation from source on this platform is non-trivial. I wouldn't recommend doing it for ordinary users.

...

So my question is, are we going to see a binary installer for OpenGL binding provided separately from either HOpenGL site, or Hackage? Or even the GHC installation page?

This would be a job for the Windows distribution team to sort out. Each other distro addresses the native packaging problem by developing packages, and what is needed for a similar team for Windows, to provide Windows packages. -- Don

Greg Fitzgerald

7:06 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

...

$ cabal install OpenGL

HOpenGL installs easily with cabal-install, but most HOpenGL examples and tutorials also use GLUT, which is not so painless on Windows. Luckily Conal Elliot just recently posted detailed instructions of how to do it: http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ -Greg On Sat, Nov 22, 2008 at 12:34 PM, Don Stewart wrote:

...

ninegua:

...
Hi everyone,

It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.

$ cabal install OpenGL

...
I'm not here to argue whether this decision by GHC dev team is right or wrong, but what's really causing the pain is that the OpenGL binding doesn't have its own binary installer for Windows, and compilation from source on this platform is non-trivial. I wouldn't recommend doing it for ordinary users.

...
So my question is, are we going to see a binary installer for OpenGL binding provided separately from either HOpenGL site, or Hackage? Or even the GHC installation page?

This would be a job for the Windows distribution team to sort out. Each other distro addresses the native packaging problem by developing packages, and what is needed for a similar team for Windows, to provide Windows packages.

-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jeff Heard

7:39 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

I'm not sure.. can MSVC compiled libraries be intermixed with mingwin libraries? I see Conal has advised installing mingwin as part of his GLUT packaging. -- Jeff On Sat, Nov 22, 2008 at 7:06 PM, Greg Fitzgerald wrote:

...

...
$ cabal install OpenGL

HOpenGL installs easily with cabal-install, but most HOpenGL examples and tutorials also use GLUT, which is not so painless on Windows. Luckily Conal Elliot just recently posted detailed instructions of how to do it:

http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/

-Greg

On Sat, Nov 22, 2008 at 12:34 PM, Don Stewart wrote:

...
ninegua:

...
Hi everyone,

It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.

$ cabal install OpenGL

...
I'm not here to argue whether this decision by GHC dev team is right or wrong, but what's really causing the pain is that the OpenGL binding doesn't have its own binary installer for Windows, and compilation from source on this platform is non-trivial. I wouldn't recommend doing it for ordinary users.

...
So my question is, are we going to see a binary installer for OpenGL binding provided separately from either HOpenGL site, or Hackage? Or even the GHC installation page?

This would be a job for the Windows distribution team to sort out. Each other distro addresses the native packaging problem by developing packages, and what is needed for a similar team for Windows, to provide Windows packages.

-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Conal Elliott

7:50 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

That post is by David Sankel (camior on #haskell), not by me. My last name has two "t"s. Good luck, - Conal (Elliott) On Sat, Nov 22, 2008 at 4:06 PM, Greg Fitzgerald wrote:

...

...
$ cabal install OpenGL

HOpenGL installs easily with cabal-install, but most HOpenGL examples and tutorials also use GLUT, which is not so painless on Windows. Luckily Conal Elliot just recently posted detailed instructions of how to do it:

http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/

-Greg

On Sat, Nov 22, 2008 at 12:34 PM, Don Stewart wrote:

...
ninegua:

...
Hi everyone,

It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.

$ cabal install OpenGL

...
I'm not here to argue whether this decision by GHC dev team is right or wrong, but what's really causing the pain is that the OpenGL binding doesn't have its own binary installer for Windows, and compilation from source on this platform is non-trivial. I wouldn't recommend doing it for ordinary users.

...
So my question is, are we going to see a binary installer for OpenGL binding provided separately from either HOpenGL site, or Hackage? Or even the GHC installation page?

This would be a job for the Windows distribution team to sort out. Each other distro addresses the native packaging problem by developing packages, and what is needed for a similar team for Windows, to provide Windows packages.

-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Paul L

11:34 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On 11/22/08, Don Stewart wrote:

...

ninegua:

...
Hi everyone,

It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.

$ cabal install OpenGL

Nice except that: 1. The command cabal requires cabal-install package to be installed, is it already bundled with all GHC 6.10.1 distributions? 2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin).

...

This would be a job for the Windows distribution team to sort out. Each other distro addresses the native packaging problem by developing packages, and what is needed for a similar team for Windows, to provide Windows packages.

Fair enough, a pitty that there is no rpm/emerge/macport equivalent for Windows. -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale

Duncan Coutts

23 Nov 23 Nov

4:37 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On Sat, 2008-11-22 at 23:34 -0500, Paul L wrote:

...

On 11/22/08, Don Stewart wrote:

...
ninegua:

...
Hi everyone,

It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.

$ cabal install OpenGL

Nice except that:

1. The command cabal requires cabal-install package to be installed, is it already bundled with all GHC 6.10.1 distributions?

It will be bundled in the Haskell platform installer (as will OpenGL). In the mean time here's a binary: http://haskell.org/~duncan/cabal/cabal.exe

...

2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin).

Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it). Duncan

Claus Reinke

7:30 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

...

...
...
...
It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.

$ cabal install OpenGL

Nice except that:

1. The command cabal requires cabal-install package to be installed, is it already bundled with all GHC 6.10.1 distributions?

It will be bundled in the Haskell platform installer (as will OpenGL).

When is that going to be available? It would be nice to know that this unfortunate gap period will end within a few weeks or so, especially since interest in Haskell OpenGL has been picking up again lately.

...

In the mean time here's a binary:

http://haskell.org/~duncan/cabal/cabal.exe

The last time I tried bootstrapping from that, I didn't get very far, nor have there been any suggestions on what to do about it: http://www.haskell.org/pipermail/cabal-devel/2008-November/004168.html

...

...
2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin).

Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it).

The problem is that this places an additional barrier on distribution: Haskell OpenGL authors cannot simply distribute their Haskell code, because many other Haskellers will not be able to get it to work: if they are on Windows: - they need to install cabal-install (before the cabal.exe, which doesn't seem to be advertized, that involved further dependency recursion http://ghcmutterings.wordpress.com/2008/11/10/bootstrapping-cabal-install/ ) - they need to install MinGW/MSys - then they can do cabal install OpenGL - there still seem to be additional issues with Glut (I haven't got around to trying it since it these things were dropped from extralibs, but the install instructions sound too complicated; patches to support freeglut should go into the glut package, manual copying around shouldn't be needed; but none of that seems to be a cabal issue) A working cabal.exe, easily found from the cabal home page, would be a good start, but several packages suffer from the "needs MinGW/MSys before cabal-install will work" issue. Since there are known-to-work versions of the MinGW/MSys installers, perhaps a cabal package wrapper for these installers could be constructed? - this would make the build dependency explicit, and would allow to record known-to-work versions via cabal dependencies - cabal could check for presence of MinGW/MSys and record the result in its package database - whenever other packages depend on MinGW/MSys, and these cannot be found, cabal could either download and run the installers from the commandline (assuming that is supported), or produce output *with precise instructions, urls, and version numbers* for manual installation (perhaps the preferred option) Then we could simply say "here is the Haskell package, use cabal (url) to build", and windows users would follow the url to download cabal.exe, and cabal.exe would tell them what they need to do to get MinGW/MSys, just as it takes care of other dependencies, and then things would "just work". Claus

Duncan Coutts

8:03 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On Sun, 2008-11-23 at 12:30 +0000, Claus Reinke wrote:

...

...
...
...
...
It's sad to see the OpenGL binding being dropped from GHC binary installers starting from 6.10. Though this issue has been brought up and discussed before, I'm sure a lot of people who based their work on OpenGL would share the same sympathy.

$ cabal install OpenGL

Nice except that:

1. The command cabal requires cabal-install package to be installed, is it already bundled with all GHC 6.10.1 distributions?

It will be bundled in the Haskell platform installer (as will OpenGL).

When is that going to be available? It would be nice to know that this unfortunate gap period will end within a few weeks or so, especially since interest in Haskell OpenGL has been picking up again lately.

The plan is for the next few weeks. But it'll be done sooner if we can get help, especially from people with access to Windows machines.

...

...
In the mean time here's a binary:

http://haskell.org/~duncan/cabal/cabal.exe

The last time I tried bootstrapping from that, I didn't get very far, nor have there been any suggestions on what to do about it:

http://www.haskell.org/pipermail/cabal-devel/2008-November/004168.html

Sorry I missed that email, let me reply now:

...

The first thing I noticed is that cabal.exe is somewhat stingy about providing information: there doesn't seem to be a "query" or "info" command and, usually, the only way to get information is to look at the "-v" output of doing something (where is the config file? cabal --help should point to it; what are the dependencies for a given package? we can only ask what cabal --install --dry-run -v is going to do with the dependencies; where do packages get unpacked temporarily, for building?..). Querying should be supported, not just doing. Am I missing something?

The cabal list command produces things like: $ cabal list opengl * OpenGL Latest version available: 2.2.1.1 Latest version installed: 2.2.1.1 Homepage: http://www.haskell.org/HOpenGL/ Category: Graphics Synopsis: A binding for the OpenGL graphics system License: BSD3 It does not list dependencies. The config file is in $HOME/.cabal/config on unix and under the per-user applications and settings directroy on Windows. This is the path returned by getAppUserDataDirectory "cabal". It's true it doesn't mention this location very often, just the first time you run cabal, when it tells you that it's making a default config file at the given location. Packages get unpacked in a subdirectory of the temp directory. What extra querying would you like? Please file feature requests with the details.

...

Having found the config file by looking at the -v output of cabal update.., I tried to enable documentation and to change every path so that cabal would use D: instead of C: (often crowded). That seemed to work, only that I missed that installs seem to be global by default, not user (also, build logs still end up on C:)?

Yes. People complained when I set the default on windows to be per-user installs. If the windows users can argue it out and come up with a consensus then we can change the defaults again. The location of the build logs should be configurable but currently is not.

...

(btw, I get lots of warnings about deprecated -ffi)

This is very tricky to solve without breaking backwards compatibility for ghc-6.4.

...

Then I tried cabal install cabal-install (ghc-6.11.20081004, cygwin), and failed.

1. cabal.exe prefers network-2.2.0.0 (installed) over network-2.2.0.1, and building that fails with a Data.Generics issue (wasn't that why the version number was bumped in the first place? and why is it built when it is installed?)

I believe this is now fixed. The ghc-6.10.0.x pre-releases came with a version of network marked as 2.2.0.0 that had different dependencies from the network-2.2.0.0 on hackage. This is what caused cabal-install to think it needed to re-install network. Of course the old version on hackage had not been updated for ghc-6.10 so it failed.

...

2. trying cabal install network explicitly does install network.2.2.0.1..

Yes. And I as I understand it, ghc-6.10.1 comes with that version. If not it's a packaging bug.

...

3. cabal install cabal-install still fails, see below

...

From the build log you pasted it looks like something is wrong with your network package.

...

...
Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it).

The problem is that this places an additional barrier on distribution: Haskell OpenGL authors cannot simply distribute their Haskell code, because many other Haskellers will not be able to get it to work:

if they are on Windows:

For the rest of the issues I think the proper solution is the platform installer which would include cabal.exe and a pre-built OpenGL. We could probably do better for packages that need mingw. Most of them record this information in the build-type: Configure, so perhaps cabal.exe should check if sh.exe is present before trying to build packages that need it. If that sounds sensible then lets file a ticket so we don't forget. Duncan

Claus Reinke

2 Dec 2 Dec

11:55 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

I finally got round to trying cabal-install with OpenGL/GLUT, using a freshly built ghc head, a cygwin bash, and

...

...
...
http://haskell.org/~duncan/cabal/cabal.exe

cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library

...

...
...
Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it).

cabal.exe opengl glut The first oddity was in the dependency resolution phase, where cabal.exe insists on installing array-0.2.0.0 and containers-0.2.0.0, which are already installed. Ignoring that, the build went through without any apparent hitch. Here is the relevant part of the build log: package: GLUT-2.1.1.2 os: windows arch: i386 compiler: ghc-6.11.20081202 client: cabal-install-0.6.0 flags: split-base dependencies: OpenGL-2.2.1.1 array-0.2.0.0 base-3.0.3.0 containers-0.2.0.0 install-outcome: InstallOk docs-outcome: NotTried tests-outcome: NotTried package: OpenGL-2.2.1.1 os: windows arch: i386 compiler: ghc-6.11.20081202 client: cabal-install-0.6.0 flags: dependencies: base-3.0.3.0 install-outcome: InstallOk docs-outcome: NotTried tests-outcome: NotTried package: array-0.2.0.0 os: windows arch: i386 compiler: ghc-6.11.20081202 client: cabal-install-0.6.0 flags: dependencies: base-4.0.0.0 syb-0.1.0.0 install-outcome: InstallOk docs-outcome: NotTried tests-outcome: NotTried package: containers-0.2.0.0 os: windows arch: i386 compiler: ghc-6.11.20081202 client: cabal-install-0.6.0 flags: dependencies: array-0.2.0.0 base-4.0.0.0 install-outcome: InstallOk docs-outcome: NotTried tests-outcome: NotTried But when I actually try to build anything using (yes, I know the explicit package flags aren't needed with --make) ghc --make -package OpenGL -package GLUT something.hs I get nothing but undefined references in the linking phase. C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake: (.text+0x15): undefined reference to `glutWarpPointer' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x3d): undefined reference to `glutReshapeWindow' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x65): undefined reference to `glutPositionWindow' ..

...

...
The problem is that this places an additional barrier on distribution: Haskell OpenGL authors cannot simply distribute their Haskell code, because many other Haskellers will not be able to get it to work:

For the rest of the issues I think the proper solution is the platform installer which would include cabal.exe and a pre-built OpenGL.

We could probably do better for packages that need mingw. Most of them record this information in the build-type: Configure, so perhaps cabal.exe should check if sh.exe is present before trying to build packages that need it. If that sounds sensible then lets file a ticket so we don't forget.

'build-type: Configure' just means that configure is needed, but says nothing about whether that is the MSys/Cygwin/.. variant of the toolchain, or which version. That would be okay if the variant/version didn't matter, but that is rarely the case. Why not have a shallow facade cabal-package for the native packages/ tools? Then cabal packages could depend on precise versions of those facade packages for windows builds, and users would know exactly what they need (and whether they have it, if the test for MSys/configure is in the msys-configure package, or where to get it, if that is documented in the facade packages; the same trick should work for other tool dependencies, such as happy/alex/..; possibly even for non-haskell library dependencies for API FFI bindings: depend on the msys-configure package, run configure to see whether library is installed, register outcome as a cabal facade package with how-to-get-it information). Btw, is the format for the cabal config file documented somewhere? I though I had set documentation to True. Claus

Duncan Coutts

12:23 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On Tue, 2008-12-02 at 16:55 +0000, Claus Reinke wrote:

...

But when I actually try to build anything using (yes, I know the explicit package flags aren't needed with --make)

ghc --make -package OpenGL -package GLUT something.hs

I get nothing but undefined references in the linking phase.

C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake: (.text+0x15): undefined reference to `glutWarpPointer'

Does ghc-pkg describe OpenGL tell you that the package needs some gl C lib? Eg "ld-options: -lGLU -lGL -lm" When you ghc --make -v, is it actually linking to a gl C lib?

...

Btw, is the format for the cabal config file documented somewhere? I though I had set documentation to True.

At the moment only in the config file itself. It lists all the fields (commented out) and where there are default values it lists those too. Duncan

Claus Reinke

1:04 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

...

...
ghc --make -package OpenGL -package GLUT something.hs I get nothing but undefined references in the linking phase. C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake: (.text+0x15): undefined reference to `glutWarpPointer'

Does ghc-pkg describe OpenGL tell you that the package needs some gl C lib? Eg "ld-options: -lGLU -lGL -lm"

Yes: $ ghc-pkg field OpenGL import-dirs,library-dirs,hs-libraries,include-dirs,includes,cc-options,ld-options import-dirs: "C:\\Program Files\\Haskell\\OpenGL-2.2.1.1\\ghc-6.11.20081202" library-dirs: "C:\\Program Files\\Haskell\\OpenGL-2.2.1.1\\ghc-6.11.20081202" hs-libraries: HSOpenGL-2.2.1.1 include-dirs: "C:\\Program Files\\Haskell\\OpenGL-2.2.1.1\\ghc-6.11.20081202\\include" includes: HsOpenGL.h cc-options: ld-options: -lglu32 -lopengl32 $ ghc-pkg field GLUT import-dirs,library-dirs,hs-libraries,include-dirs,includes,cc-options,ld-options import-dirs: "C:\\Program Files\\Haskell\\GLUT-2.1.1.2\\ghc-6.11.20081202" library-dirs: "C:\\Program Files\\Haskell\\GLUT-2.1.1.2\\ghc-6.11.20081202" hs-libraries: HSGLUT-2.1.1.2 include-dirs: "C:\\Program Files\\Haskell\\GLUT-2.1.1.2\\ghc-6.11.20081202\\include" includes: HsGLUT.h cc-options: ld-options: -lglut32 -lglu32 -lopengl32

...

When you ghc --make -v, is it actually linking to a gl C lib?

It looks that way: *** Linker: (slightly reformated) C:\ghc\ghc-6.11.20081202\gcc -BC:\ghc\ghc-6.11.20081202\gcc-lib/ -IC:\ghc\ghc-6.11.20081202\include/mingw/ -v -o Lift.exe -DDONT_WANT_WIN32_DLL_SUPPORT obj\Main.o obj\FunWorlds.o obj\Scene.o obj\Behavior.o C:\DOCUME~1\cr3\LOCALS~1\Temp\/ghc3144_0/ghc3144_0.o -LC:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202 -LC:\Program Files\Haskell\containers-0.2.0.0\ghc-6.11.20081202 -LC:\Program Files\Haskell\OpenGL-2.2.1.1\ghc-6.11.20081202 -LC:\ghc\ghc-6.11.20081202\haskell98-1.0.1.0 -LC:\ghc\ghc-6.11.20081202\random-1.0.0.1 -LC:\ghc\ghc-6.11.20081202\process-1.0.1.1 -LC:\ghc\ghc-6.11.20081202\directory-1.0.0.2 -LC:\ghc\ghc-6.11.20081202\old-time-1.0.0.1 -LC:\ghc\ghc-6.11.20081202\old-locale-1.0.0.1 -LC:\ghc\ghc-6.11.20081202\filepath-1.1.0.1 -LC:\ghc\ghc-6.11.20081202\Win32-2.2.0.0 -LC:\ghc\ghc-6.11.20081202\bytestring-0.9.1.4 -LC:\Program Files\Haskell\array-0.2.0.0\ghc-6.11.20081202 -LC:\ghc\ghc-6.11.20081202\base-3.0.3.0 -LC:\ghc\ghc-6.11.20081202\syb-0.1.0.0 -LC:\ghc\ghc-6.11.20081202\base-4.0.0.0 -LC:\ghc\ghc-6.11.20081202\integer-0.1.0.0 -LC:\ghc\ghc-6.11.20081202\ghc-prim-0.1.0.0 -LC:\ghc\ghc-6.11.20081202 -LC:\ghc\ghc-6.11.20081202/gcc-lib -lHSGLUT-2.1.1.2 -lglut32 -lglu32 -lopengl32 -lHScontainers-0.2.0.0 -lHSOpenGL-2.2.1.1 -lglu32 -lopengl32 -lHShaskell98-1.0.1.0 -lHSrandom-1.0.0.1 -lHSprocess-1.0.1.1 -lHSdirectory-1.0.0.2 -lHSold-time-1.0.0.1 -lHSold-locale-1.0.0.1 -lHSfilepath-1.1.0.1 -lHSWin32-2.2.0.0 -luser32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSbytestring-0.9.1.4 -lHSarray-0.2.0.0 -lHSbase-3.0.3.0 -lHSsyb-0.1.0.0 -lHSbase-4.0.0.0 -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lgmp -lwsock32 -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -u _base_GHCziConc_runSparks_closure -lHSffi $ ls C:/ghc/ghc-6.11.20081202/gcc-lib/*gl* C:/ghc/ghc-6.11.20081202/gcc-lib/CRT_noglob.o C:/ghc/ghc-6.11.20081202/gcc-lib/libglut.a C:/ghc/ghc-6.11.20081202/gcc-lib/libglaux.a C:/ghc/ghc-6.11.20081202/gcc-lib/libglut32.a C:/ghc/ghc-6.11.20081202/gcc-lib/libglu32.a C:/ghc/ghc-6.11.20081202/gcc-lib/libopengl32.a

...

...
Btw, is the format for the cabal config file documented somewhere? I though I had set documentation to True.

At the moment only in the config file itself. It lists all the fields (commented out) and where there are default values it lists those too.

ah, I wasn't sure whether those '--' were meant to indicate options or commenting (a comment in the first line might make usage unambiguous?-) Claus

Duncan Coutts

6:24 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On Tue, 2008-12-02 at 18:04 +0000, Claus Reinke wrote:

...

...
...
ghc --make -package OpenGL -package GLUT something.hs I get nothing but undefined references in the linking phase. C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake: (.text+0x15): undefined reference to `glutWarpPointer'

Does ghc-pkg describe OpenGL tell you that the package needs some gl C lib? Eg "ld-options: -lGLU -lGL -lm"

Yes:

Then I've no idea. Is it missing all symbols or is it just a few? Does your GL dll actually contain those symbols. This doesn't immediately appear to me to be a Cabal/cabal-install problem. Perhaps we can ask for some wider help with this one.

...

...
...
Btw, is the format for the cabal config file documented somewhere? I though I had set documentation to True.

At the moment only in the config file itself. It lists all the fields (commented out) and where there are default values it lists those too.

ah, I wasn't sure whether those '--' were meant to indicate options or commenting (a comment in the first line might make usage unambiguous?-)

Good idea. Duncan

Pekka Karjalainen

2:33 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On Tue, Dec 2, 2008 at 6:55 PM, Claus Reinke wrote:

...

I finally got round to trying cabal-install with OpenGL/GLUT, using a freshly built ghc head, a cygwin bash, and [...]

...

C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake: (.text+0x15): undefined reference to `glutWarpPointer' [...]

I believe these errors are caused by the wrong calling convention being used in the Haskell bindings. This part in the configure script tests the build (host) platform: case "$host" in *-mingw32) CALLCONV=stdcall ;; *) CALLCONV=ccall ;; esac Since it doesn't test for Cygwin, you end up with the calling convention being ccall, which leads to the linker errors because of associated name mangling (you would also see run-time crashes if you managed to somehow link your program). Pekka

Claus Reinke

2:57 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

...

I believe these errors are caused by the wrong calling convention being used in the Haskell bindings. This part in the configure script tests the build (host) platform:

case "$host" in *-mingw32) CALLCONV=stdcall ;; *) CALLCONV=ccall ;; esac

Since it doesn't test for Cygwin, you end up with the calling convention being ccall, which leads to the linker errors because of associated name mangling (you would also see run-time crashes if you managed to somehow link your program).

Ah, that makes sense! And, indeed, for the archives, this workaround fixes the issue (even when building from cygwin bash): cabal install opengl glut --configure-option="--host=i386-unknown-mingw32" --reinstall Thanks, now FunWorlds can ride again!-) I suppose we could document this on the OpenGL wiki, but even better would be a fix to OpenGL's configure (apart from checking the build environment (mingw) rather than the host (cygwin here), it should ensure that the build uses exactly what configure has tested successfully) or .cabal (allways setting the --host configure option if on windows)? [cc-ed to hopengl list, since this seems to be an OpenGL-specific issue, not a general Cabal one; Cabal++ :-] Claus PS of course, a high-level interpretation of the linker errors, by cabal or by ghc, would also help in such cases (linking object code is a ghc-internal detail, we work with Haskell code!-).

Manlio Perillo

23 Nov 23 Nov

10:41 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

Claus Reinke ha scritto:

...

[...]

...
...
2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin).

[...] - they need to install MinGW/MSys - then they can do cabal install OpenGL

Does cabal support precompiled packages? Regards Manlio Perillo

Duncan Coutts

11:31 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On Sun, 2008-11-23 at 16:41 +0100, Manlio Perillo wrote:

...

Claus Reinke ha scritto:

...
[...]

...
...
2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin).

[...] - they need to install MinGW/MSys - then they can do cabal install OpenGL

Does cabal support precompiled packages?

You can construct a pre-compiled packages from a Cabal package (using an external tool like cabal2rpm). The cabal command line tool has no support for installing such things. Normally one makes native pre-compiled packages like .deb, .rpm, .msi etc and then uses the native system for actually installing them. Duncan

Paul L

8 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On 11/23/08, Duncan Coutts wrote:

...

...
2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin).

Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it).

Sure, I don't doubt it. The real trouble is the extra dependency to MinGW/MinSys. I'm reluctant to tell my users to go installing them just for the sake of compiling HOpenGL. Really, OpenGL is the only true cross-platform Graphics solution because it comes as default installation on all platforms. Nothing else comes close to my mind. On a side note, since GHC installation for Windows contains a version of gcc, I wonder how hard it would be to replace the autoconf compilation of HOPenGL with just cabal. Then we'll get rid of the MinGW/MinSys depedency all together. Isn't it the purpose of cabal to replace non-portable build systems (for Haskell at least)? -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale

Duncan Coutts

8:12 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On Sun, 2008-11-23 at 08:00 -0500, Paul L wrote:

...

On 11/23/08, Duncan Coutts wrote:

...
...
2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin).

Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it).

Sure, I don't doubt it. The real trouble is the extra dependency to MinGW/MinSys. I'm reluctant to tell my users to go installing them just for the sake of compiling HOpenGL.

Sure, we're currently in an intermediate situation where the ghc release is smaller but we've not had the first platform release yet. We're only suggesting cabal install opengl on windows for developers, not for your users.

...

On a side note, since GHC installation for Windows contains a version of gcc, I wonder how hard it would be to replace the autoconf compilation of HOPenGL with just cabal. Then we'll get rid of the MinGW/MinSys depedency all together. Isn't it the purpose of cabal to replace non-portable build systems (for Haskell at least)?

That may well be possible and wherever it is possible we should do it. The MinGW dependency is certainly a pain. Consider this an invitation for anyone to go take a look at the configure scripts for these packages and see how easy they'd be to replace with pure Haskell in the Setup.hs. Duncan

Jeff Heard

9:24 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

Duncan, what kind of help do you need on the Haskell Platform install? I have access to VMs running windows XP and Vista. On Sun, Nov 23, 2008 at 8:12 AM, Duncan Coutts wrote:

...

On Sun, 2008-11-23 at 08:00 -0500, Paul L wrote:

...
On 11/23/08, Duncan Coutts wrote:

...
...
2. It still wouldn't work for the OpenGL package on Windows, because the configure scripts require a Unix-style built environment (MinGW/MinSys or Cygwin).

Yes, building it requires mingw/msys, but with it cabal install opengl really does work (I've tried it).

Sure, I don't doubt it. The real trouble is the extra dependency to MinGW/MinSys. I'm reluctant to tell my users to go installing them just for the sake of compiling HOpenGL.

Sure, we're currently in an intermediate situation where the ghc release is smaller but we've not had the first platform release yet.

We're only suggesting cabal install opengl on windows for developers, not for your users.

...
On a side note, since GHC installation for Windows contains a version of gcc, I wonder how hard it would be to replace the autoconf compilation of HOPenGL with just cabal. Then we'll get rid of the MinGW/MinSys depedency all together. Isn't it the purpose of cabal to replace non-portable build systems (for Haskell at least)?

That may well be possible and wherever it is possible we should do it. The MinGW dependency is certainly a pain. Consider this an invitation for anyone to go take a look at the configure scripts for these packages and see how easy they'd be to replace with pure Haskell in the Setup.hs.

Duncan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Duncan Coutts

10:12 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

On Sun, 2008-11-23 at 09:24 -0500, Jeff Heard wrote:

...

Duncan, what kind of help do you need on the Haskell Platform install? I have access to VMs running windows XP and Vista.

The haskell-platform meta-package is here: darcs get http://code.haskell.org/haskell-platform/ This specifies the list of packages and their exact versions. We need to make sure this builds ok on all platforms. So that's the first step. We plan to use the same windows installer builder that ghc uses, but to install a few more packages. The inno setup script is in the ghc tree in distrib/ghc.iss So the second step if you want to help with that is getting the existing ghc installer building ok. We'll start from a binary install image of ghc, then build the non-core libs and add them to the install image. Finally we build the installer. As much as possible we want to automate this and keep the scripts in the haskell-platform repo. Duncan

Simon Peyton-Jones

24 Nov 24 Nov

4:10 a.m.

New subject: [Haskell] GHC 6.10 and OpenGL

| It's sad to see the OpenGL binding being dropped from GHC binary | installers starting from 6.10. Though this issue has been brought up | and discussed before, I'm sure a lot of people who based their work on | OpenGL would share the same sympathy. The plan (which we have perhaps not articulated as clearly as we should) is this: - We are trying to make the GHC release contain as few libraries as possible - Instead, you get the "batteries" for GHC (ie the libraries) from the Haskell Platform http://www.haskell.org/haskellwiki/Haskell_Platform This lets GHC HQ get out of the library business, and makes it easier to upgrade libraries independently from GHC. But it does mean that GHC without the batteries is a feeble thing. You really want to wait until the HP comes out. The HP will be released in source form, to be installed by cabal-install, of course. But I believe that the intention is that there should be a Windows installer for it too. Things I am less clear about - When will the first HP release compatible with GHC 6.10 appear? - How do users get cabal-install in the first place? Is there a windows installer for it? - Where can one find an up-to-date list of what packages are in HP? - Is there anyone who is actually planning to do the work of making a windows installer for the HP? The HP home page lists only Duncan and Don. I think it'd be good if it was easy to answer these questions from the HP home page. Simon

Don Stewart

2:38 p.m.

New subject: [Haskell] GHC 6.10 and OpenGL

simonpj:

...

| It's sad to see the OpenGL binding being dropped from GHC binary | installers starting from 6.10. Though this issue has been brought up | and discussed before, I'm sure a lot of people who based their work on | OpenGL would share the same sympathy.

The plan (which we have perhaps not articulated as clearly as we should) is this:

- We are trying to make the GHC release contain as few libraries as possible - Instead, you get the "batteries" for GHC (ie the libraries) from the Haskell Platform http://www.haskell.org/haskellwiki/Haskell_Platform

This lets GHC HQ get out of the library business, and makes it easier to upgrade libraries independently from GHC. But it does mean that GHC without the batteries is a feeble thing. You really want to wait until the HP comes out.

The HP will be released in source form, to be installed by cabal-install, of course. But I believe that the intention is that there should be a Windows installer for it too.

Things I am less clear about - When will the first HP release compatible with GHC 6.10 appear?

Next few weeks.

...

- How do users get cabal-install in the first place? Is there a windows installer for it?

Via binaries for their platform (e.g. windows .exe's).

...

- Where can one find an up-to-date list of what packages are in HP?

The definitive version, http://code.haskell.org/haskell-platform/haskell-platform.cabal There's also a bug tracker.

...

- Is there anyone who is actually planning to do the work of making a windows installer for the HP? The HP home page lists only Duncan and Don.

We need a Windows platform champion, as we do for other distros, who's in the business of making native packages for that key system. Neil?

...

I think it'd be good if it was easy to answer these questions from the HP home page.

Yes! -- Don

6014

Age (days ago)

6024

Last active (days ago)

List overview

Download

22 comments

10 participants

participants (10)

Claus Reinke
Conal Elliott
Don Stewart
Duncan Coutts
Greg Fitzgerald
Jeff Heard
Manlio Perillo
Paul L
Pekka Karjalainen
Simon Peyton-Jones