The programs on the disc are supplied in binary form for the most popular UNIX platforms, as listed in article 52.3 . But we also supply C source code for those of you who are on unsupported platforms.
Now, don't run away. You don't have to be a C programmer to compile these sources. I've never written a C program in my life, and I compile public domain software all the time. The CD-ROM provides build scripts for each of the packages, so many of you can just run the script and have everything installed automatically.
If the build scripts don't work, the CD-ROM also has a script to copy the sources to your local hard disk. Although we can't promise that you'll be able to build the sources on your own without a hitch, this article includes some explanation of how to build sources without needing to learn how to program in C.
Before you do anything, try out the build scripts. You might be able to get away without knowing anything at all about the build process.
To build programs from source code, first mount the CD-ROM as described in article 52.5 .
Each package on the CD-ROM that has source code can be compiled with the "build" script. The build script will copy the files off the CD into your current directory, compile, and install them.
As the CD-ROM is read-only, you must use a directory on some other disk for the build. For example, if you wanted to build the "compress" package, a directory called compress will be created in the current directory when the build script is run. The build script has default settings for the directory to which the source code will be copied, the directory in which the package will be installed, the directory in which the "shareable" portion of the package will be installed, and a "prefix" for the shareable directories. These settings can be overridden by the following:
By default, the files generated by the build process will not be removed. If you set the RM variable before running the build, the entire build directory will be removed once the build finishes:
For a list of the available packages, run the build.pt script in the CD-ROM mount directory. The actual name of the script depends on your operating system (as described in article 52.5 ), but assuming that the CD-ROM is mounted on /cdrom , it is likely to be one of the following commands:
The command will print a list similar to the following:
bash bsdtar bsplit calen cpmod cvtbase delete diff ediff emacs fgrep fileutils find gawk getopt glimpse grabchars grep ...
To build one of these packages, run the same command followed by the package name. For example:
The build script will copy the package to the current directory, compile, and install the package according to the values of the environment variables. For this example, the shareable and non-shareable portions of the package are combined.
% /archive/cdrom/BUILD.PT jot BUILD script provided by Ready-to-Run Software, Inc. Copyright 1997 Ready-to-Run Software, Inc. All Rights Reserved. Assuming CDROM is mounted at /archive/cdrom Assuming MACHINE is ALPHA Assuming SOURCEDIR is /archive/cdrom/SOURCES Ignore any errors about directories already existing tools/ tools/BUGS tools/Makefile tools/jot.c tools/lam.c tools/rs.c cc -O -o jot jot.c
Some of the build scripts expect non-standard programs to be installed. Some of these come on the CD-ROM:
Some other utilities are not included:
Any number of things can go wrong with your build. You might not have the right libraries or include files installed. Your compiler may not work the way the program expects it to. You might not have the right permissions. You might run out of disk space.
These problems are so varied that there's no way we can list any generalized solutions. Try asking an administrator or programmer on your site, or try calling . But we have a few tips that might help:
And if all else fails, you can try to delve into the source code itself. That brings us to our next section ...
Almost all UNIX binary programs are written in the C language. These programs are written in text files - the text files are referred to as the source code -and then converted to binary files using a compiler . The typical compiler on a UNIX system is called cc .
Although most people call cc a "compiler," it's really a front-end program. Unless you tell it not to, cc first runs a preprocessor . Next it runs the compiler. Then it runs the linker/loader to make the actual executable file. We'll gloss over that in this article and just say that "cc does it."
On top of cc , there's usually another front-end: almost all programs are designed to be compiled using the make program.
Although we can't prepare you for everything you might need to know to compile programs from the CD-ROM for your platform, this section should at least give you an idea of how it's supposed to work.
Before you can actually compile the sources, you need to copy the sources to your local hard disk. You can't just compile the sources directly from the CD-ROM because the CD-ROM is read-only.
The first thing you need to do is to decide where you want to install the sources, and then cd to that directory. For example, I like to build sources in a subdirectory of my home directory. Let's suppose I want to install the pcal program. I create the new directory and then cd there:
For installing the sources onto your local hard disk, the CD-ROM has a script called source.pt . Assuming that the CD-ROM is mounted on /cdrom , the script can be called using one of the following commands:
Where package-name is the name of the package that you want to install sources for. To get a listing of the files, call source.pt without any arguments:
% source.pt SOURCE script provided by Ready-to-Run Software, Inc. Copyright 1997 Ready-to-Run Software, Inc. All Rights Reserved. Assuming CDROM is mounted at /archive/cdrom/ Usage: /archive/cdrom/SOURCE.PT <package Available packages are: ! 80cols Clear _emacs_ml _enter_csh _enter_sh _exit_csh _exit_sh addup age_files ascii awf bash behead bkedit bsdtar bsplit cal_today calen catsaway center cgrep cgrep_sed checksed chmod_edit chunksort cleanup cleanup_sed cls cols count_it count_types cpmod crontab crush csh_init csh_logout cvtbase date-month del delete diff dir_path dirtop doublespace ediff elookfor emacs exrc fgrep fileutils find findcmd findtext flip fmt_sh formprog ftpfile gawk getmac getopt glimpse grabchars grep groff gzip head hey hgrep index ipl ispell jot lensort less lf lndir logerrs longlines look lookfor ls_today make_print manindex motd_diff namesort netpbm nextday no_run nom offset oldlinks opttest paircheck patch pcal perl5 phone pipegrep pstext psutils pushin qcsh qsubst qterm rcs rcsegrep_fast rcsgrep rcsrevs recomment redo relink ren rename rot runsed runtime sc screen screensize script_tidy search_el sedman sh_init sh_logout sharutils shellutils showmatch sl sls smiley squoze stat stree stripper su tar tcap tcsh termtest textutils tgrep tknew tm tpipe tputinit triplespace twin vgrep vis vtree watchq whereiz which wordfreq xgrep xtail zap zloop zmore zvi
(Note that all the packages on the CD-ROM are listed here, shell scripts as well as C sources.)
The source.pt script copies all the relevant files into your current directory.
If you now list the directory, you'll find the files that were just copied there.
The file called pcal-4.3.tar.Z is the pcal source package, in a tarred and compressed form. The .Z suffix tells you that the file was compressed using thecommand. You need to run uncompress first:
To unpack the file, use tar with the -x option for "extract" and the -f option to specify a filename. (I also like to use -v for verbose output.) My command line might read:
tar creates a subdirectory called pcal-4.3 . cd to this directory to continue your build.
Note that if you have the zcat command, you might have combined the steps for uncompressing and untarring the files into a single command line, as shown in article 19.7 :
If you are on a System V-based system, you may have to use tar with theto make sure that you get ownership of the files.
Before we go on, let's back up a bit. Some packages aren't stored as tar archives, but as . shar archives are generally distributed in multiple files, under names such as part01.Z , part02.Z , etc. The qterm source package is an example of a package that is distributed as shar files.
If you don't have shar and unshar , it's on the CD-ROM; but the true beauty of shar archives is that you can always remove any headers and footers from the file and use the Bourne shell (sh ) to unpack the files.
To edit out the header, remove any lines at the top of the
file that don't resemble Bourne shell syntax.
Since many shar
archives are distributed in email or in newsgroups, the files
might include the header of a mail message or news posting.
The author might also precede the actual shar
some explanation of what the program does.
A good bet is to look for a line
(text .... ) #! /bin/sh # This is a shell archive. Remove anything before this line, # then feed it into a shell via "sh file" or similar. # To overwrite existing files, type "sh file -c".
To remove the footer, look for anything resembling a user's mail signature. (shar archives usually have an exit message at the end, so editing out the footer isn't always needed ... but it doesn't hurt.)
Note that it's especially important to install and unpack shar archives in discrete, well-named directories (such as qterm_src , in this case). Since shar files are almost always given generic names of part01 , part02 , etc., it's easy to overwrite files or to get confused if you accidentally unpack more than one package in the same directory.
When I copied the pcal sources using the source.pt shell script, I also got two : rtrpatch.pcal and RS6000patch.pcal . These are patches prepared by Ready-to-Run Software for compiling the pcal package.
The RS6000patch.pcal file is a patch for compilng on IBM's RS6000 platform. If you aren't on a RS6000, then you probably don't need this file. When building other packages, you might see other platform-specific patch files, with prefixes like i386 , xenix , hp700 , sun3 , sun4 , etc. Naturally, you shouldn't use these packages if you aren't on one of these platforms.
The rtrpatch.pcal file is a general-purpose patch for all platforms. You should apply this patch for all platforms.
Before you apply any of Ready-to-Run's patches, you should first make sure that there aren't any patch files in the untarred source directory. If the sources did come with patch files, they would have to be applied before Ready-to-Run's. In the pcal-4.3 directory, list the directory contents:
A patch file generally has the string patch or pch in it. There are no patch files in this directory. Now that I'm sure that there aren't any other patches, I run the patch command. (Naturally, if you don't already have patch , you can get its sources off the CD-ROM.) To run patch , make sure you're in the source directory (in this case, the pcal-4.3 subdirectory created when I ran tar ). Then run patch , taking input from the patch file in the parent directory:
The patch is now applied.
Up to now, all we've been doing is just getting the source tree together. Now we're up to the part where we actually build the package.
README files often contain esoteric details about the history of the program and what improvements could be made, etc. But they might also contain details about how to build the package. Reading a README can save you hours of frustration trying to figure out what to tweak to make the program build on your platform.
Another file to look for is one called Configure . Configure is a shell script that tries to figure out what sort of platform you're on and how to build the package for you, and it's remarkably effective. The sources for perl and patch both come with Configure scripts.
pcal doesn't come with a README or with a Configure script. But it does come with a file called Makefile . (Actually, it comes with several Makefiles , for different platforms - but the default Makefile is the one for UNIX systems, which is what you want.) The Makefile is used by. There have been entire books written about make , but if you're lucky, all you need to know about it is that if you see a Makefile , then all you need to compile a program is to type make .
First, though, scan through the Makefile to see if there are any comments there. You might have to make some changes in the Makefile to configure it for your system. For example, the qterm Makefile has the following very helpful lines:
# # Add "-DUSG5" to DEFS below, if your system is UNIX System V. # Add "-DHAS_VARARGS" if your system supports varargs. # Add "-DOPT_COMPAT" to support old command line options. # DEFS = -DTABFILE=\"$(TABFILE)\" -DOPT_COMPAT
You probably know whether your system is System V-based or not. If you never used this program before, you probably don't care about old command line options. And if you don't know what varargs are or whether your system supports it ... try seeing if there's afor it. (You might even find out what it is!)
What do you know, I have varargs
So I add the
DEFS = -DTABFILE=\"$(TABFILE)\" -DOPT_COMPAT -DHAS_VARARGS
The pcal Makefile , on the other hand, only includes a single line of instruction towards the top:
# Set the configuration variables below to taste.
This isn't particularly helpful, but scan the Makefile anyway for anything obviously wrong. When you're satisfied, just cross your fingers and run make :
There were no error or warning messages, so you're fine. Errors mean that the program package probably didn't build completely; you'll have to find the cause and fix them. If there were warnings, the programs may not work right or have a subtle flaw. For a program like a spreadsheet, where hidden flaws can be a disaster, you'd better find out what the warnings mean and fix them. Otherwise, just cross your fingers some more and see if the program works.
When you list the pcal source directory now, you should see several new files with a .o suffix, but the most important thing is that the pcal executable is now built and ready to be installed on your system.
You can now try out the program, and once you're sure it works, install it. To install the program, many Makefiles provide an install target.
On many machines, you'll need to be logged in as root to be able to install the binary and manpage system-wide. If so, it might be a good idea to run make with the -n option first. The -n option says to just show what commands would be executed without actually executing them.
Or if you prefer to just install the program by hand, just move the executable and the manpage to the right directories (be sure to rename the manpage as appropriate):
Note, however, that some programs may have extra steps in installing the executable. If all this worked as advertised, you can bail out now. Otherwise, you might need to know more about what goes on behind the scenes before you can figure out what went wrong.
C programs are written almost entirely using functions . Article 15.3 shows an example of a function defined in the Bourne shell programming language. C language functions are basically the same idea: group together a series of commands, give them a name, and then you can execute those commands using that name whenever you want and as many times as you want. Functions are also sometimes referred to as subroutines , library functions , or just routines .
Now, you can define C functions in the same source file. But the operating system also provides a vast collection of function definitions - which is very nice, because otherwise you'd be building every program from scratch. The function definitions are kept in libraries , which are generally installed on your system in /usr/lib/ with a lib prefix and a .a suffix (for example, /usr/lib/libc.a ).
Functions also have to be declared in the program. Function declarations are kept in header or include files, which are generally installed on your system in /usr/include/ with .h suffixes (for example, /usr/include/stdio.h ).
If you use functions that are defined in libraries (and you most definitely will), you need to make sure that when the program is compiled, it is linked to the libraries it needs. You also have to make sure that the proper header files are read by your program, since the program won't compile unless all functions have been declared.
For example, if you need to take the square root of a number in your program, you need to use the sqrt() function. This function resides in the Math library. This means that you need to link the program with libm.a and you need to read in the math.h header file (which declares sqrt() ). So in the program, you need to have the following line near the top of the source file:
and when you compile the program, you need to use the -l (lowercase L) command-line option to link with libm :
Note the following facts:
As you can imagine, there's much more to know. But that's the general idea of compiling C programs on UNIX systems, and it's about as much as we can tell you without starting to teach you C.
But more complicated programs (like many of the programs on the CD-ROM) require a bit more work. More complicated programs are easier to handle if you write them in modules . So, for example, the pcal source tree on the CD-ROM contains several .c files: exprpars.c , moonphas.c , pcalinit.c , pcalutil.c , readfile.c , writefil.c , and, of course, pcal.c . Each of these source files needs to be compiled separately into object files (with .o suffixes). If you give the -c option, cc will compile ".c files" into ".o files" and stop without making the finished executable. When you run cc again - but give it the .o filenames (exprpars.o , moonphas.o , and so on) it will link all those object files with the libraries and make the executable file.
This makes compilation a bit harder to keep track of. There are a lot more steps. Furthermore, it means that whenever a file is changed, you have to remember not only to recompile it but also to relink the entire program.
This is a job for the make program. We showed uses for make in articles 21.9 and 28.13 , but this is what it was really meant for. The pcal source tree comes with a file called Makefile . (Actually, it comes with several different Makefile s for different platforms, but that's another issue.) The Makefile keeps track of each of the programs and each of their dependencies. It also keeps track of any command-line options you might want passed to cc , including libraries to link to. The result is that when you want to make the pcal program, all you need to do is type:
Or, even better, just:
This is a lot easier than trying to keep track of all the modules and command-line options yourself.
So if you can't compile a program because the header file it needs is
installed in a non-standard place, you'd specify that in the
You could add the appropriate -I
option to the
COPTS = -I/usr/include/sys
Or if you want to use a different compiler than cc , you could redefine that variable:
CC = /usr/local/bin/gcc
Again, this is only the tip of the iceberg. But a basic understanding of libraries, header files, and make has helped me build many programs that wouldn't compile the first time. For help with make , see O'Reilly & Associates' Managing Projects with make by Andrew Oram and Steve Talbott.