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 " -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

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&atid=300003 http://cvs.sourceforge.net/viewcvs.py/mesa3d/Mesa/demos/Makefile.am?r1=1.29&r2=1.30

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