This article was originally posted on the Lanka Linux User Group site.
What is a Tarball?
Tar was originally developed as a backup software for unix (Tape Archiving program). It collects several files to a single file (or standard output). A problem with the original tar program was that it could not compress data by itself, so another program called gzip, had to be used. Gzip is slightly different from other compression programs such as PKZip, ARJ, LHA or RAR. It operates only on one file and it does not create a new zip file. Instead it converts the old file to a compressed file and adds the extention '.gz', so the original file is no longer there. When decompressing, it simply works the other way round, converting the compressed file to the original file and removing the extension.
When it comes to collect several files (including subdirectories) to one single file, tar and gzip is used in combination. The command
tar -cvf myfile.tar *
will create a tar archive called myfile.tar, collecting all the files in the current directory/subdirectories. The option 'c' is for create, 'v' is to be verbose, i.e., to list the files that is being compressed, and 'f' to tell tar to write its output to the file whose name follows ('myfile.tar' in this example). If you did not give a filename with an 'f' option, output will be written to the standard output, and the screen will be filled with garbage. Type 'reset' to get the console back to the normal condition if this happens. The above tar file is then gzipped.
and 'myfile.tar' will be converted to 'myfile.tar.gz'.
Modern tar programs can do compression too. Therefore it is not necessary to run tar and gzip seperately. Instead just passing an option 'z' to tar will do the compression. Hence the above two commands are equivalent to
tar -czvf myfile.tar.gz *
Usually a software package comes with a set of files in a tar.gz archive. If the package name is 'mypackage' and its version number is 'x.xx', the archive is usually named 'mypackage-x.xx.tar.gz. To check its contents, give the command
tar -tzvf mypackage-x.xx.tar.gz
and to untar it
tar -xzvf mypackage-x.xx.tar.gz
Usually this will create a directory 'mypackage-x.xx' in the current directory and place the rest of the files, usually known as the 'source tree', under it. However, there are some rare cases, where the files will be created in the current directory (e.g. xfractint). In this case, it is necessary to create a directory for the source tree and untar the package in it. It is always a good idea to test the contents with the option 't' beforehand.
Some packages may have the extention 'tgz' instead of 'tar.gz'. In early stages of development, some packages use the release date instead of version number (e.g. wine).
Where to Untar a Package?
First, let us have a brief look at the unix directory tree. The following list gives some directories and their contents.
- bin : binary files (executables)
- sbin : system binary files
- etc : configuration files
- include : include files
- lib : library files
- src : source files
- doc : document files
- man : manual files
- share : shared files
These directories exist in various levels. For example consider the 'bin' directory. There are several places where you get 'bin' directories
- /bin : This is where you get standard unix commands such as 'ls', 'cd', 'mail' etc.
- /usr/bin : Here you will find the commands that came with the Linux distribution (such as gnuplot, pine)
- /usr/local/bin : Packages that are installed in addition to the original distribution comes here
- ~/bin : Uses can have their personal executables here
- /usr/X11/bin : X window executables (usually X11 is a pointer to X11R6
The story is more or less the same for the other directories. The root directory has standard unix directories. '/usr' has files related to the original installation. '/usr/local' has things that were added in addition to the distribution and finally the home directories may contain user specific directories.
There are few deviations too. For example '/etc' is shared by both standard unix programs as well as the programs that comes with a distribution.
Since, we are interested in compiling packages in addition to the original distribution, we will have to use the '/usr/local' directory. It is usual to untar source trees under '/usr/local/src', and to keep the tarballs under '/usr/local/tar'. Therefore, the process of extracting the source tree will be
cd /usr/local/src tar -tzvf ../tar/mypackage-xx.x.tar.gz tar -xzvf ../tar/mypackage-xx.x.tar.gz
Several software packages are built upon libraries. It is a good idea to have often needed libraries installed. Here is a brief list of them. Most of them are for the GUI.
- GTK : the Gimp toolkit. This usually comes with many distributions.
- Motif : Standard GUI toolkit for unix. A free clone called 'lesstif' has been developed by hungry programmers. Available as 'sources' or 'binaries'
- Mesa : A free implementation of OpenGL.
- SDL : This is the simple direct media layer. Is used by several games such as Quake
- xforms : Another GUI library. Used by lyx, the front end to latex
To compile you need both the library and its header files. RPMs are usually available in pairs. For example, Mesa library has Mesa-xxxx.i386.rpm and Mesa-devel-xxxx.i386.rpm. The later contains the header files necessary to complile.
Several of the above libraries are available as binaries and it is easy for new users to install them that way instead of compiling them. RedHat users can get most of the libraries in RPM format from redhat powertools (see redhat mirrors - some of them don't mirror powertools bundle).
Configuring the Source Tree
Most packages come with a 'configure' script which is at the root of source tree. Just running './configure' is fine, but the following changes may be useful.
- Remove the occurences of '-g' from the script if you don't want debug information in binaries. Also give the options '--disable-debug' and '--disable-trace' when running 'configure'.
- Type './configure --help', which will list the options that can be passed to the configure script.
- It is a good idea to check the created Makefile(s).
- If the 'configure' script stops with an error, read the error message carefully. Most errors can be corrected then and there by carefully editing the script or installing necessary packages/libraries.
Static vs. Dynamic Libraries
Static libraries are the ones that are linked to the programs at the compile time. For example /usr/lib/libm.a is the math library and is linked to a program by giving the option -lm. A static library xyz has the filename libxyz.a and can be linked to a program by giving the option -lxyz. If the library is not in the default library path, you have to give the option 'L/foo/bar' to specify the path to the libraries. If a compilation stops with the error which indicates the absence of a library and if you know that the library is somewhere (find it by 'find / -name "libxyz.a"'), specify its location by the -L option or edit the corresponding Makefile.
Dynamically linkded libraries have the extension 'so'. The file /etc/ld.so.conf contains the directories where these libraries are found. If you add a new library to a directory which is not listed there, edit that file and run ldconfig.
Usually the default include directories are '/usr/include' and '/usr/local/include'. Some programs expect include files to be in a subdirectory. For example Xlib include files are in a X11 subdirectory and C programs will have the line
#include <X11/Xlib.h>There are rare cases the program conflicts with the include file locations. Here is an example. The Flight Gear flight simulator needs the header files from plib library to be in a plib directory (/usr/include/plib or /usr/local/include/plib). However, the default installation of plib copies the include files to /usr/local/plib/include. To overcome the problem you can add a link from /usr/local/include to /usr/local/plib/include with the name plib (ln -s /usr/local/plib/include plib). Now there is a /usr/local/include/plib (actually /usr/local/plib/include) and it will contain plib include files.
Compiling and Installing
Usually compiling and installing are done by giving the commands 'make' and 'make install'. It is safe to do a 'make check' before 'make install' to make sure things are well.
Some system administrators like to compile software as a user rather than root and login as the root only to do the installation (make install). This is good if make takes a long time and leaving the computer with a root shell is unsecure.
README and INSTALL
Usually the source tree contains a README file (may be more than one) and an INSTALL file. Read them FIRST!. They contain valuble information that will save time. Remember that some packages have unconventional installation procedures.