Course Software

Subroutine Libraries

Commands

For previewing animation:

For viewing stills and image processing:

fluid is the user interface design program for FLTK, and fdesign is the corresponding program for Xforms, as mentioned previously. They are in the class bin directory.

I suggest you set your path automatically by putting something like 

set path=($path /afs/cs/academic/class/15462/bin)
in your .cshrc to get these programs with minimum hassle.

UNIX Compilation

The include files for Mesa, FLTK, Xforms, libpicio, and libtiff are in /afs/cs/academic/class/15462/include, so if you compile with gcc -I/afs/cs/academic/class/15462/include, your source code can use, for example 
#include <GL/gl.h>  /* for OpenGL */
#include <pic.h>    /* for libpicio */
#include <FL/Fl.H>  /* for FLTK */
to include some of the more important include files.

UNIX Linking

The Makefiles we provide will link the starter code correctly on cluster Sun and Linux machines, so hopefully you won't need to muck with the following much. Typical link sequences, if you're using FLTK, are: 
on Linux: -lfltk -lGLU -lGL -lX11 -lXext -lm 
on Sun: -lfltk -lGLU -lGL -lX11 -lXext -lsocket -lm 
on SGI: -lfltk -lGLU -lGL -lX11 -lm
If you're using Xforms as the user interface library instead of FLTK, then replace -lfltk with -lforms. If you're linking with the pic_ and tiff_ routines, then you'll need -lpicio -ltiff as well. If for some reason you want the old, soon-to-disappear version of Mesa mentioned above, use -lMesaGLU -lMesaGL instead of -lGLU -lGL.

A quick tutorial on UNIX libraries: Subroutine libraries come in two forms, .a files and .so files. When you make an executable, subroutines are ``linked'' to the main program. If you compile with -lfoo, the compiler by default looks for the archive file libfoo.a, and if it doesn't find it, it looks for the shared object file libfoo.so. These files are searched for in the list of directories given in -L options to the C/C++ compiler, then in the directories listed in the shell variable $LD_LIBRARY_PATH, then in the default directory /usr/lib. See "man ld" for more details. When an archive file (.a) is linked, the appropriate subroutines from the object files (.o) are copied, making your executable larger, but ensuring that it will always run (on the right architecture). When a shared object file (.so) is linked, the subroutines are not copied and compile/link time. Instead, at run time, the system uses LD_LIBRARY_PATH to find the .so file and the appropriate subroutines are dynamically linked into your executable in memory. This results in much smaller executable files, but it means that if you copy your executable to another machine without copying all of the .so's it references, your program won't run. The upshot of this is that LD_LIBRARY_PATH must be set correctly or something is likely to fail.

You'll need the command 

setenv LD_LIBRARY_PATH /afs/cs/academic/class/15462/lib:/usr/lib:/usr/local/lib
It's a good idea to put this command in your .login . On the Suns, if you're using -lGLU -lGL, it's critical that you list the class lib directory before /usr/lib and /usr/local/lib, or you'll get Sun's version of OpenGL (from /usr/lib), rather than Mesa's. Our experience is that Sun's OpenGL doesn't work well on Suns having only 8 bits per pixel (the colormap is wrong). You can, of course, check this variable with 
echo $LD_LIBRARY_PATH

On an SGI, you'll probably also need 

setenv LD_LIBRARYN32_PATH /usr/local/lib32
for shared object files such as libforms.so and libGL.so to be resolved correctly.

You can get a list of shared object files that a given executable needs with ldd <PROGRAM>.

Working on a Non-Cluster UNIX/Linux Machine

If you want to set up so you can program the assignments directly on a non-cluster machine, without remote login to a cluster machine, you'll need to do some extra work, namely copy the include files and libraries. In order to compile code, you'll need the include files. Copy the include directory hierarchy to your machine. (We currently have different versions for each architecture, but I think the differences are insignificant, so copy any of them.) Then you'll need the libraries for linking. Figure out what architecture your remote (e.g. home) machine is. If it's an Intel processor running Linux, then copy the directory hierarchy in arch/i386_linux2/include. If it's a Sun Sparc, copy arch/sun4_55/include. To copy a hierarchy, the easy way to do it is
cp -r source-dir dest-dir
Another way to do it is:
mkdir dest-dir
cd dest-dir
(cd source-dir; tar cfL - .) | tar xvf -
The L option to tar tells it to follow symbolic links. You'll probably want option this to help grab files that come from outside the 462 hierarchy such as the header files for libpicio and libtiff.

If your machine is not a Sun or a Linux machine (an Alpha, say) then the first thing to do is check the web pages for the libraries above (Mesa, FLTK, etc) to see if a compiled library is available for your architecture already. If not, you'll need to get the source and recompile. If it was written by someone at CMU and it's used in this course, you should find the source code in the class src directory.

Documentation

To get documentation via the "man" program, put this 
setenv MANPATH /usr/share/catman:/usr/share/man:/usr/catman:/usr/man:/usr/local/man:/afs/cs/academic/class/15462/man
in your .login or equivalent shell initialization file.
15-462, Computer Graphics 1
Paul Heckbert, Feb. 2000