|
|
< Day Day Up > |
|
Linux software applications in the form of source code are available at different sites on the Internet. You can download any of this software and install it on your system. Recent releases are often available in the form of compressed archive files. Applications will always be downloadable as compressed archives, if they don't have an RPM version. This is particularly true for the recent versions of GNOME or KDE packages. RPM packages are only intermittently generated.
Though you can decompress and extract software in separate operations, you will find that the more common approach is to perform both actions with a single command. The tar utility provides decompression options you can use to have tar first decompress a file for you, invoking the specified decompression utility. The z option automatically invokes gunzip to unpack a .gz file, and the j option unpacks a .bz2 file. Use the Z option for .Z files. For example, to combine the decompressing and unpacking operation for a tar.gz file into one tar command, insert a z option to the option list, xzvf ( see the section "Extracting Software" later in this chapter for a discussion of these options). The next example shows how you can combine decompression and extraction in one step:
# tar xvzf htdig-3.1.6.tar.gz
For a .bz2 compressed archive, you would use the j option instead of the z option.
# tar xvjf htdig-3.1.6.tar.bz2
Many software packages under development or designed for cross-platform implementation may not be in an RPM format. Instead, they may be archived and compressed. The filenames for these files end with the extension .tar.gz, .tar.bz2, or .tar.Z. The different extensions indicate different decompression methods using different commands: gunzip for .gz, bunzip2 for .bz2, and decompress for .Z. In fact, most software with an RPM format also has a corresponding .tar.gz format. After you download such a package, you must first decompress it, and then unpack it with the tar command. The compressed archives could hold either source code that you then need to compile or, as is the case with Java packages, binaries that are ready to run.
A compressed archive is an archive file created with tar, and then compressed with a compression tool like gzip. To install such a file, you must first decompress it with a decompression utility like gunzip utility, and then use tar to extract the files and directories making up the software package. Instead of the gunzip utility, you could also use gzip -d. The next example decompresses the htdig-3.1.6.tar.gz file, replacing it with a decompressed version called htdig-3.1.6.tar:
# ls htdig-3.1.6.tar.gz # gunzip htdig-3.1.6.tar.gz # ls htdig-3.1.6.tar
You can download compressed archives from many different sites, including those mentioned previously. Downloads can be accomplished with FTP clients such as ncftp and Gftp, or with any Web browser, such as Mozilla. Once downloaded, any file that ends with .Z, .bz2, .zip, or .gz is a compressed file that must be decompressed.
For files ending with .bz2, you would use the bunzip2 command. The following example decompresses the Java 2 SDK downloaded from www.blackdown.org:
# bunzip2 j2sdk-1.3.0-FCS-linux-i386.tar.bz2 # ls j2sdk-1.3.0-FCS-linux-i386.tar
Before you unpack the archive, move it to the directory where you want it. Source code packages should be placed in the /usr/local/src directory, and binary packages go in designated directories. Source code files are unpacked in the /usr/local/src directory, generating their own subdirectories from which you can compile and install the software. Once it is installed, you can delete this directory, keeping the original source code package file (.tar.gz).
Packages that hold binary programs ready to run, like Java, are meant to be extracted in certain directories. Usually this is the /usr/local directory. Most archives, when they unpack, create a subdirectory named with the application name and its release, placing all those files or directories making up the software package into that subdirectory. For example, the file cdrchive-1.2.2.tar unpacks to a subdirectory called cdrchive-1.2.2. In certain cases, the software package that contains precompiled binaries is designed to unpack directly into the system subdirectory where it will be used. For example, it is recommended that j2sdk-1.3.0-FCS- linux-i386.tar be unpacked in the /usr/local directory, where it will create a subdirectory called j2sdk-1.3.0. The /usr/local/j2sdk-1.3.0/bin directory holds the Java binary programs.
First, use tar with the t option to check the contents of the archive. If the first entry is a directory, then when you extract the archive, that directory is created and the extracted files are placed in it. If the first entry is not a directory, you should first create one and then copy the archive file to it. Then extract the archive within that directory. If no directory exists as the first entry, files are extracted to the current directory. You must create a directory yourself to hold these files.
# tar tvf htdig-3.1.6.tar
Now you are ready to extract the files from the tar archive. You use tar with the x option to extract files, the v option to display the pathnames of files as they are extracted, and the f option, followed by the name of the archive file:
# tar xvf htdig-3.1.6.tar
The extraction process creates a subdirectory consisting of the name and release of the software. In the preceding example, the extraction created a subdirectory called htdig-3.1.6. You can change to this subdirectory and examine its files, such as the README and INSTALL files.
# cd htdig-3.1.6
Installation of your software may differ for each package. Instructions are usually provided along with an installation program. Be sure to consult the README and INSTALL files, if included. See the following section on compiling software for information on how to create and install the application on your system.
Some software may be in the form of source code that you need to compile before you can install it. This is particularly true of programs designed for cross-platform implementations. Programs designed to run on various Unix systems, such as Sun, as well as on Linux, may be distributed as source code that is downloaded and compiled in those different systems. Compiling such software has been greatly simplified in recent years by the use of configuration scripts that automatically detect a given system's hardware and software configuration and then allow you to compile the program accordingly. For example, the name of the C compiler on a system could be gcc or cc. Configuration scripts detect which is present and select it for use in the program compilation.
A configure script works by generating a customized Makefile, designed for that particular system. A Makefile contains detailed commands to compile a program, including any preprocessing, links to required libraries, and the compilation of program components in their proper order. Many Makefiles for complex applications may have to access several software subdirectories, each with separate components to compile. The use of configure and Makefile scripts vastly automates the compile process, reducing the procedure to a few simple steps.
First change to the directory where the software's source code has been extracted:
# cd /usr/local/src/cdrchive-1.2.2
Before you compile software, read the README or INSTALL files included with it. These give you detailed instructions on how to compile and install this particular program.
Most software can be compiled and installed in three simple steps. Their first step is the ./configure command, which generates your customized Makefile. The second step is the make command, which uses a Makefile in your working directory (in this case the Makefile you just generated with the ./configure command) to compile your software. The final step also uses the make command, but this time with the install option. The Makefile generated by the ./configure command also contains instructions for installing the software on your system. Using the install option runs just those installation commands. To perform the installation, you have to be logged in as the root user, giving you the ability to add software files to system directories as needed. If the software uses configuration scripts, compiling and installing usually involves only the following three simple commands:
# ./configure # make # make install
In the preceding example, the./configure command performs configuration detection. The make command performs the actual compiling, using a makefile script generated by the ./configure operation. The make install command installs the program on your system, placing the executable program in a directory, such as /usr/local/bin, and any configuration files in /etc. Any shared libraries it created may go into /usr/local/lib.
Once you have compiled and installed your application, and you have checked that it is working properly, you can remove the source code directory that was created when you extracted the software. You can keep the archive file (tar) in case you need to extract the software again. Use rm with the -rf options so that all subdirectories will be deleted and you do not have to confirm each deletion:
# rm -rf cdrchive.1.2.2
| Tip |
Be sure to remember to place the period and slash before the configure command. ./ references a command in the current working directory, rather than another Linux command. |
Certain software may have specific options set up for the ./configure operation. To find out what these are, you use the ./configure command with the --help option.
# ./configure --help
A useful common option is the -prefix option, which lets you specify the install directory:
# ./configure -prefix=/usr/bin
| Tip |
Some older X applications use xmkmf directly instead of a configure script to generate the needed Makefile. In this case, enter the command xmkmf in place of ./configure. Be sure to consult the INSTALL and README files for the software. |
If you are compiling an X-, GNOME-, or KDE-based program, be sure their development libraries have been installed. For X applications, be sure the xmkmf program is also installed. If you chose a standard install when you installed your distribution system, these most likely were not installed. For distributions using RPM packages, these come in the form of a set of development RPM packages, usually with the word "development" or "develop" in their names. You need to install them using either rpm or redhat-config-packages. GNOME, in particular, has an extensive set of RPM packages for development libraries. Many X applications need special shared libraries. For example, some applications may need the xforms library or the qt library. Some of these you may need to obtain from online sites.
Libraries can be either static, shared, or dynamic. A static library is one whose code is incorporated into the program when it is compiled. A shared library, however, has its code loaded for access whenever the program is run. When compiled, such a program simply notes the libraries it needs. Then when the program is run, that library is loaded and the program can access its functions. A dynamic library is a variation on a shared library. Like a shared library, it can be loaded when the program is run. However, it does not actually load until instructions in the program tell it to. It can also be unloaded as the program runs, and another library could be loaded in its place. Shared and dynamic libraries make for much smaller code. Instead of a program including the library as part of its executable file, it only needs a reference to it.
Libraries made available on your system reside in the /usr/lib and /lib directories. The names of these libraries always begin with the prefix lib followed by the library name and a suffix. The suffix differs, depending on whether it is a static or shared library. A shared library has the extension .so followed by major and minor version numbers. A static library simply has the .a extension. A further distinction is made for shared libraries in the old a.out format. These have the extension .sa. The syntax for the library name is the following:
libname.so.major.minor libname.a
The name can be any string, and it uniquely identifies a library. It can be a word, a few characters, or even a single letter. The name of the shared math library is libm.so.5, where the math library is uniquely identified by the letter m and the major version is 5. libm.a is the static math library. The name of the X Window library is libX11.so.6, where the X Window library is uniquely identified with the letters X11 and its major version is 6.
Most shared libraries are found in the /usr/lib and /lib directories. These directories are always searched first. Some shared libraries are located in special directories of their own. A listing of these is placed in the /etc/ld.conf configuration file. These directories will also be searched for a given library. By default, Linux first looks for shared libraries, then static ones. Whenever a shared library is updated or a new one installed, you need to run the ldconfig command to update its entries in the /etc/ld.conf file as well as links to it (if you install from an RPM package, this is usually done for you).
If no configure script exists and the program does not use xmkmf, you may have to edit the software's Makefile directly. Be sure to check the documentation for such software to see if any changes must be made to the Makefile. Only a few changes may be necessary, but more detailed changes require an understanding of C programming and how make works with it. If you successfully configure the Makefile, you may only have to enter the make and make install commands. One possible problem is locating the development libraries for C and the X Window System. X libraries are in the /usr/X11R6/lib directory. Standard C libraries are located in the /usr/lib directory.
Programs and commands are usually installed in several standard system directories, such as /bin, /usr/bin, /usr/X11R6/bin, or /usr/local/bin. Some packages place their commands in subdirectories, however, which they create within one of these standard directories or in an entirely separate directory. In such cases, you may be unable to run those commands because your system may be unable to locate them in the new subdirectory. Your system maintains a set of directories that search for commands each time you execute one. This set of directories is kept in a system variable called PATH that is created when you start your system. If a command is in a directory that is not in this list, your system will be unable to locate and run it. To use such commands, you first need to add the new directory to the set of directories in the PATH variable. Installation tools like RPM will automatically update the PATH with the appropriate directories for you.
On Red Hat systems, the PATH variable is originally assigned in the /etc/rc.d/rc.sysinit file and further added to by different services that start up when the system boots. You could edit /etc/rc.d/rc.sysinit file directly, but you would have to be very careful not to change anything else. A safer approach is to add a PATH definition in the /etc/profile file.
To make an application available to all users, you can add the software's directory to the path entry in the /etc/profile script. The /etc/profile script is a system script executed for each user when the user logs in. Carefully edit the /etc/profile file using a text editor, such as KEdit, gedit, Emacs, or Vi (you may want to make a backup copy first with the cp command). You add a line that begins with PATH, followed by an = sign, and the term $PATH, followed by a colon, and then the directory to be added. The $ before PATH extracts the pathname from the PATH variable. If you add more than one directory, be sure a colon separates them. You should also have a colon at the end. For example, if you install the Java 2 SDK, the Java commands are installed in a subdirectory called j2sdk-1.3.0/bin in the /usr/local directory. The full pathname for this directory is /usr/local/j2sdk-1.3.0/bin. You need to add this directory to the list of directories assigned to PATH in the /etc/profile file. The following example shows the PATH variable with its list of directories and the /usr/local/j2sdk-1.3.0/bin directory added. Notice the $ before PATH after the = sign, PATH=$PATH.
PATH=$PATH:/usr/local/j2sdk-1.3.0/bin
After making your changes you can execute the profile file to have the changes take effect.
$ . /etc/profile
Individual users can customize their PATH variables by placing a PATH assignment in either their .bashrc or .bash_profile file. In this way, users can access commands and programs they create or install for their own use in their own user directories (see Chapter 9 for more details). On Red Hat, user .bash_profile files already contain the following PATH definition. Notice the use of $PATH, which keeps all the directories already added to the PATH in previous startup scripts like /etc/profile and /etc/rc.d/rc.sysinit.
PATH=$PATH:$HOME/bin
The following entry in the .bash_profile file adds a user's newbin directory to the PATH variable. Notice both the colon placed before the new directory and the use of the $HOME variable to specify the pathname for the user's home directory.
PATH=$PATH:$HOME/bin/:$HOME/newbin
For the root user, the PATH definition also includes sbin directories. The sbin directories hold system administration programs that the root user would need to have access to. The root user PATH is shown here:
PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH:$HOME/bin
|
|
< Day Day Up > |
|
| This HTML Help has been published using the chm2web software. |