15-463 Course Software

The software setup for this course is nearly identical to that for 15-462.

Subroutine Libraries


For previewing animation:

For viewing stills and image processing:

fluid is the user interface design program for FLTK, as mentioned previously. It is in the class bin directory.

I suggest you set your path automatically by putting something like

set path=($path /afs/andrew/scs/cs/15-463/pub/bin)

in your .cshrc or .login to get these programs with minimum hassle.

UNIX Compilation

The include files for Mesa, FLTK, libpicio, and libtiff are in /afs/andrew/scs/cs/15-463/pub/bin, so if you compile with gcc -I/afs/andrew/scs/cs/15-463/pub/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 linking with the pic_ and tiff_ routines, then you'll need -lpicio -ltiff as well.

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/andrew/scs/cs/15-463/pub/lib:/usr/lib:/usr/local/lib
It's a good idea to put this command in your .login . On the Suns, 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

On an SGI, you'll probably also need

setenv LD_LIBRARYN32_PATH /usr/local/lib32
for shared object files such as libfltk.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. On many systems you can do this by running "sys"; If it's an Intel processor running Linux, then copy the directory hierarchy in pub/arch/i386_rh60/include. If it's a Sun Sparc, copy pub/arch/sun4_57/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 463 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.


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/andrew/scs/cs/15-463/pub/man
in your .login or equivalent shell initialization file.
15-463, Computer Graphics 2
Paul Heckbert, Jan. 2001