ANNOUNCE: HOpenGL 1.05 released
HOpenGL, a Haskell binding for OpenGL and GLUT version 1.05 I am pleased to announce the sixteenth release of the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the* industrial strength 3D graphics API and a GUI toolkit. More details about HOpenGL can be found at http://haskell.org/HOpenGL/ This is a compatibility/bug fix release with the following changes: * Fixed a memory allocation bug for GL state queries. * Works with new hierarchical libraries now. * Always use the correct calling convention. * The build system works with recent versions of GHC and GreenCard now. As always, feedback and/or patches are highly welcome. A note for people on the bleeding edge: If you are interested in the future of HOpenGL and its new API, you might wish to build GHC from CVS, configuring with `--enable-hopengl'. This will result in a GHC with two additional packages `OpenGL' and `GLUT'. The APIs have improved quite a bit and are now modeled around the notion of state variables. Furthermore, OpenGL's extension mechanism is now supported on all major platforms, including Linux, Windows and Mac OS X. Note that this is still work in progress, but early feedback would be very useful. Have fun! Sven
"SP" == Sven Panne <Sven.Panne@informatik.uni-muenchen.de> writes:
SP> I am pleased to announce the sixteenth release of SP> the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT SP> 3.7beta. I'm trying to build it on Fedora Core 1 with ghc-6.0.1, greencard-3.01, XFree86-Mesa-libGL and freeglut-1.3-1.20020125.3. The library seems to build ok, but when I try to build the examples I get: cd /home/petersen/haskell/HOpenGL/HOpenGL-1.05/examples/misc/ LANG=C make "/usr/bin/ghc" -o Info -i../../lib:../../GLUT -I../../lib -package lang -fglasgow-exts -I/usr/X11R6/include "-#include <GL/freeglut.h>" -O Info.o -L../../lib -lHOpenGL -lGLU -lGL -lSM -lICE -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -lfreeglut-1.3 -lm /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../../libfreeglut-1.3.so: undefined reference to `XF86VidModeSetViewPort' /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../../libfreeglut-1.3.so: undefined reference to `XF86VidModeSwitchToMode' /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../../libfreeglut-1.3.so: undefined reference to `XF86VidModeGetAllModeLines' /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../../libfreeglut-1.3.so: undefined reference to `XF86VidModeGetModeLine' collect2: ld returned 1 exit status make: *** [Info] Error 1 I tried adding -lXxf86vm to the link invocation but that didn't help. Any ideas? Jens configure output: checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for greencard... /usr/bin/greencard checking for ghc... /usr/bin/ghc checking for etags... /usr/bin/etags checking for hstags... no configure: WARNING: Using etags as a replacement for hstags checking for ghc-pkg... /usr/bin/ghc-pkg checking for xargs... yes checking how to run the C preprocessor... gcc -E checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for main in -lm... yes checking for library containing glEnd... -lGL checking glTexSubImage1D... yes checking glDrawRangeElements... yes checking glActiveTexture... yes checking glMultiDrawArrays... no configure: It looks like GL version 1.3 checking EXT_blend_color... yes checking EXT_blend_minmax... yes checking EXT_blend_subtract... yes checking for library containing gluNewQuadric... -lGLU checking gluGetString... yes checking gluTessEndPolygon... yes checking gluUnProject4... yes configure: It looks like GLU version 1.3 checking for library containing glXWaitX... none required checking for library containing glutMainLoop... no checking OpenGL flags... -I/usr/X11R6/include checking OpenGL libs... -lGLU -lGL -lSM -lICE -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -lm
Jens Petersen wrote:
SP> I am pleased to announce the sixteenth release of SP> the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT SP> 3.7beta.
I'm trying to build it on Fedora Core 1 with ghc-6.0.1, greencard-3.01, XFree86-Mesa-libGL and freeglut-1.3-1.20020125.3. The library seems to build ok, but when I try to build the examples I get:
cd /home/petersen/haskell/HOpenGL/HOpenGL-1.05/examples/misc/ LANG=C make "/usr/bin/ghc" -o Info -i../../lib:../../GLUT -I../../lib -package lang -fglasgow-exts -I/usr/X11R6/include "-#include <GL/freeglut.h>" -O Info.o -L../../lib -lHOpenGL -lGLU -lGL -lSM -lICE -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -lfreeglut-1.3 -lm /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../../libfreeglut-1.3.so: undefined reference to `XF86VidModeSetViewPort' /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../../libfreeglut-1.3.so: undefined reference to `XF86VidModeSwitchToMode' /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../../libfreeglut-1.3.so: undefined reference to `XF86VidModeGetAllModeLines' /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../../libfreeglut-1.3.so: undefined reference to `XF86VidModeGetModeLine' collect2: ld returned 1 exit status make: *** [Info] Error 1
I tried adding -lXxf86vm to the link invocation but that didn't help. Any ideas?
Ultimately this is an error in libfreeglut; if it needs the XF86VidMode* functions, it should link against libXxf86vm when building the shared library. You should be able to work around the problem by adding -lXxf86vm to the link command, but it has to come *after* the -lfreeglut-1.3 switch. -- Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
[...] You should be able to work around the problem by adding -lXxf86vm to the link command, but it has to come *after* the -lfreeglut-1.3 switch.
Glad to hear this. :-) Some people on this mailing list had linking troubles, especially with GHCi and GLUT/GLU/GL. AFAIK there are basically two kinds of platforms: Ones where the relative order of libraries on the linker commandline does not matter and ones where you have to mention a library B used by a library A after it, i.e. in the order "-lA -lB". Solaris falls in this category, see e.g. my patches submitted to the Mesa project: http://sourceforge.net/tracker/index.php?func=detail&aid=544638&group_id=3&a... http://cvs.sourceforge.net/viewcvs.py/mesa3d/Mesa/demos/Makefile.am?r1=1.29&... If the GLUT package doesn't work with GHCi on some platforms, the exact circumstances would be interesting. On x86 Linux the order "-lglut -lGLU -lGL <some X11 libs>" works perfectly. Perhaps there are some dlopen() incompatibilities between different platforms. Any experts in this area on this list? Cheers, S.
Sven Panne wrote:
[...] You should be able to work around the problem by adding -lXxf86vm to the link command, but it has to come *after* the -lfreeglut-1.3 switch.
Glad to hear this. :-) Some people on this mailing list had linking troubles, especially with GHCi and GLUT/GLU/GL. AFAIK there are basically two kinds of platforms: Ones where the relative order of libraries on the linker commandline does not matter and ones where you have to mention a library B used by a library A after it, i.e. in the order "-lA -lB". Solaris falls in this category, see e.g. my patches submitted to the Mesa project:
http://sourceforge.net/tracker/index.php?func=detail&aid=544638&group_id=3&a... http://cvs.sourceforge.net/viewcvs.py/mesa3d/Mesa/demos/Makefile.am?r1=1.29&...
If the GLUT package doesn't work with GHCi on some platforms, the exact circumstances would be interesting. On x86 Linux the order "-lglut -lGLU -lGL <some X11 libs>" works perfectly. Perhaps there are some dlopen() incompatibilities between different platforms. Any experts in this area on this list?
I'm no expert, but I'll add the following: The ordering is usually important for static libraries; on some platforms, it may also be important for shared libraries, but that is less common. A static library is simply an archive of object files (similar to a zip file, but simpler), possibly with the addition of an index (usually generated by ranlib). When a static library is used in the link command, the linker only includes those object files which are actually required to satisfy unresolved symbols. If that the libraries are processed in the order listed on the command line, only unresolved symbols from the object and library files which have been processed up to that point ar considered. Any unresolved symbols in libraries which appear after a given static library won't be considered in determining which object files to use from the static library. [Aside: there appears to be a "feature" in the MacOS X linker (at least, up to and including that in 10.2), namely that it only considers symbols which correspond to functions (not variables) when determining which of a library's object files are required. If a library member is only required for the variables which it defines, it won't be included in the link.] For maximum reliability, the libraries should appear in the link command in order of their depth in the dependency tree; each library should appear after any libraries which require it. In the event of circular dependencies (which are generally considered bad design, but occasionally occur), it may be necessary to list a library more than once. Even when this isn't necessary, it won't do any harm. -- Glynn Clements <glynn.clements@virgin.net>
participants (3)
-
Glynn Clements -
Jens Petersen -
Sven Panne