Linux with Operating System Concepts

beta-test release
, meaning 
that the software is not fully developed or debugged), you are presented with a list of files 
to select from.
There may also be a subdivision in the software listed based on the intended architecture 
and platform. This becomes necessary if the code uses operating system functions. More 
commonly, there will be a division of operating system platform but not of processor type. 
You may find both executable programs and source code. The executable programs are 
already compiled, meaning that they are easily installed but not configurable. The source 
code consists of many files and subdirectories packaged using the tar program. Most of 
the time, such a bundle will also be compressed using the gzip format or the bz2 format so 
that these files will end with the extension .tar.gz or .tar.bz2. You might also find encrypted 
versions using one of PGP, MD5, or SHA1 (among others).
13.5.2 Extracting from the Archive
Once the package has been downloaded, your next step is to extract the files from its 
archive. This is typically taken care of by issuing a single tar command. If, for instance, you 
are installing the package 
somepackage
version 3.1.8, you will have probably downloaded 
a file like 
somepackage
-3.1.8.tar.gz
(the numbers represent the version and release 
numbers). Now you issue the command
tar –xzf somepackage-3.1.8.tar.gz

---

548
◾
Linux with Operating System Concepts
The x option performs file extraction from the archive, the z option uncompresses the file 
using gunzip, and the f indicates that the accompanying filename should be used.
As the package itself most likely contains a directory of files (and subdirectories), 
extracting from the package results in an entire file structure being created and popu-
lated with the directories and subdirectories from the tar file. Assuming our file was called 
somepackage-3.1.8.tar.gz, the above command should create a directory called somepack-
age-3.1.8. With the directory created, we cd into that directory.
Inside the software’s installation directory, we will most likely see a great number of 
files and subdirectories (depending upon the size of the software package). Among the files 
will be a 
README
file. This text file contains the instructions for installation, alerting the 
system administrator to any specific requirements and options for installation. There may 
be other text files such as 
LICENSE
, 
CHANGES
, 
NOTIFICATION
(or 
NOTICE
), 
ABOUT
, 
and 
VERSION
. There will also be at least one script file present, 
makefile
(alternatively 
Makefile
or 
Makefile.in
). The 
makefile
is used to compile and install the software. 
There may also be a 
configure
file. The configure file is a script containing Bash instruc-
tions to create or modify the makefile file(s).
Among the subdirectories you will most likely find 
build
(containing C program 
code), 
docs
(man page documentation or other forms of documentation), 
include
(C 
library files), and 
modules
(containing add-on code that the system administrator might 
wish to add to increase the functionality of the software).
Figure 13.8 comes from untarring the open source package apg (automated password 
generator). Here, we see that most of the source code (the .c and .h files) is located in the 
top-level directory. The subdirectories of 
bfconvert
, 
cast
, and 
sha
contain additional 
source code for extra functionality. The 
perl
subdirectory contains perl code to be used if 
you want apg to run on a server. The files whose names are all in capital letters are instruc-
tions, acknowledgments, and a to-do list. The two scripts, 
install-sh
and 
mkin-
stalldirs
, are controlling scripts like those found in /etc/init.d. That is, they are used 
to start and stop the apg program as if it were a service. Finally, 
Makefile
contains the 
compilation and installation operations. The apg software was packaged without a 
con-
figure
script, so any changes that you want to make to the compilation and installation 
process would have to be done by hand by altering 
Makefile
yourself.
Assuming the package contains all necessary code, and assuming your system has the 
proper software already installed to compile and install the given package, the next steps 
should be straightforward. If not, it usually means that your system is not set up as the 
installation process expects (i.e., the original programmer(s) expects certain files in certain 
FIGURE 13.8 
Contents of untarred open source archive.

---

Software Installation and Maintenance
◾
549
directories and if that is not the case, the installation may fail). If the installation is not as 
expected, you as the system administrator may have to make changes to the 
configure
file, 
makefile
, or other files. It is therefore critical that you review the 
README
and other 
installation documentation files first.
13.5.3 Running the configure Script
The first step may be optional, which is to run the 
configure
script. If there is already 
a 
makefile
present and you are not making modifications, you may be able to skip the 
configure step. If however there is no file named 
makefile
(or 
Makefile
), then you 
must run 
configure
. You might find, for instance, 
Makefile.in
. This is not a 
make-
file
. It is instead a partial 
makefile
that will be used as a starting point by 
config-
ure
. 
configure
will output a new file called 
makefile
to be used in the next step. 
Additionally, if you wish to alter the default installation, you would specify these changes 
through the 
configure
script as a series of options.
If you are dealing with a large piece of software, chances are either the 
README
file or 
configure
itself will include instructions on how to use configure. To execute configure, 
since it is a script, you would specify .
/configure
. To obtain help, you might try .
/con-
figure -h
(or --
help
). Some of the options available in configure might be to specify 
destination directories and modules to compile. You might find, for instance, the following 
options available:
• 
--bindir
=