Information on building and using Systems software for College of Computing Users

Acquiring source code

First, seriously consider whether or not you need to build your own copy of the libraries. The software distributed by the Systems group is available pre-built in /users/c/chaos/, as discussed below.

For those who need it, software source is available directly from the CVS source repository at /users/c/chaos/CVSmaster. Access to this repository is granted only to members of the Unix group "chaos". Generally, you'll only need this if you are doing development on one of the libraries. Otherwise, the publicly available distributions on ftp.cc.gatech.edu. These distributions will not be the absolute latest, but they should represent stable and functional versions. If these don't work for you because you must have the latest and greatest or because you must use software which we don't distribute publicly, consider using the pre-built libraries. If that won't work for some reason, talk to someone involved in the maintenance of the library about becoming a member of the "chaos" group or getting a more up-to-date release in some other way.

Building from source

Generally, all of our software comes with a configure script. This is a /bin/sh script that examines system-specific characteristics and generates the appropriate Makefile and config.h files for the machine on which your are building. (It caches those characteristics in the file config.cache. Remember to remove that file if you build for a different architecture in the same directory!) Most configure scripts have optional arguments that affect the way the software is configures. Running "configure --help" will print those options.

Many of our projects depend upon other projects. The configure script automatically searches for those projects' libraries and include files so that it can add the correct -I and -L arguments to compile and link lines. It first searches `pwd`/.., then $HOME, then /users/c/chaos and uses the first that it finds. Warning: If you work on several different architectures, having a project built for a different architecture laying around can result in a failed configure or a failed build.

Some of our distributions build differently depending upon what they find or where they find themselves. For example, builds outside of the gatech.edu domain may default to use different servers. Others will build more limited versions of themselves if certain projects are not available. For example, DataExchange will build without derived event channels if dynamic code generation is not found and without threading support if the project gen_threads is not found. Generally this is noted in the output from configure.

Configure can also be affected by various environment variables. For example, configure prefers to use gcc if it is available, but will use the compiler specified by the $CC environment variable if it is set.

Using pre-built libraries

 All pre-built libraries are available in /users/c/chaos/lib/$ARCH where $ARCH is the string printed by /users/c/chaos/bin/hppcel_arch. Binaries are in /users/c/chaos/bin/$ARCH. Include files are in /users/c/chaos/include and /users/c/chaos/bin/$ARCH. (If you make regular use of this stuff, adding /users/c/chaos/bin and /users/c/chaos/bin/$ARCH to your path is a good idea.) Libraries are built for each architecture every night (unless the source for that library and the ones it depends upon have not changed). Regression tests are run before installation and the install is not performed if the tests fail. However, few packages have bullet-proof regression tests, so if you use the packages from /users/c/chaos there remains the possibility that a bug will be introduced or that other changes will invalidate your code. Obviously we try to minimize changes that are not backwards compatible, but they do happen, sometimes accidently. If your use is such that you cannot tolerate the possibility of change, copy the libraries to some safe place and use them there. Also, before sending Email of the form "My program worked yesterday, today it's broken, I didn't change anything, so you must have broken it" please triple-check. Nine times out of ten it's the program, not the library, that is at fault.

Architecture-specific notes