Compiling Source Code I

Summary:

• Compiling Basics
• Unpacking Archives
• Important Files to Read
• Needed Packages

Compiling Basics

A program is written using a programming language. Some languages, the so-called 'script languages', allow you to run written programs right away. Popular examples for these kind of languages are Perl, Python and Tcl/Tk. They come with an interpreter which serves as an translator between the program and the system.

Other languages like C or C++ require the written program to be compiled to a 'binary' before it can be run.

Each approach has its pros and cons: Interpreted programs require less time to develop, whereas binary programs do not need an interpreter and thus run faster, and are usually better suited for complex tasks.

Compiling translates the human-readable text, the 'source', into a machine-readable file, the 'binary'. So the first thing you need for compiling is a compiler. In Linux, that's 'gcc' for programs written in C (the majority), and 'g++' (aka 'gcc-c++') for programs written in C++.
Complex programs can consist of large number of source files. In order to make the compilation easier, compilation instructions are often listed in a file, the 'Makefile'. To make use of this file, you need the program 'make'. 'make' reads through ('parses') the Makefile and provides the compiler with the appropriate options. You can change these options (like for instance where the compiled files will be installed) by editing the 'Makefile'.

When writing programs, the programmer doesn't write the whole program. He or she relies on 'libraries' which supply a set of commonly used functions. The programmer just sets a 'link' in the source file referring to a certain library or a function in that library. The compiled binary will need this library to run.
Now, if you compile the program, the compiler will need access to some of the source files of each library the program depends on. These files are called 'header files'. So you will need these, too.
Since you need these header files only for compiling, it might be sensible to split RPM-packaged libraries into two: one package which contains the files needed to run a program and one package which contains the files needed to compile a program. And this is indeed what is now commonplace in distributions: one package contains the library itself (the 'runtime version') and a second package, marked with '-devel-' (for 'development'), contains the header files.
So, you will need the packages which contain the header files of the libraries the program depends on ,too.

You might ask yourself how you are supposed to know which libraries a program needs. The 'simplest' way would be trying to compile the source. The compilation process will bail out if it can't find a needed library.
The second possibility is having a look at the Makefile itself. At the beginning there is a line starting with LIBS =, which lists all the libraries needed. Notice that they are listed in some sort of shorthand: '-lX11' for example is shorthand for the filename 'libX11.so'. Do a locate libX11.so to find out if this file is installed on your system.
A third mechanism is the 'configure' script, which a programmer can produce using the autoconf or autoscan program. autoconf uses the file 'configure.in' and checks your system if all the needed libraries and functions are available on your system. If not, it will fail and tell you what's wrong. Then start the ./configure to create the Makefile and other files. Use make to compile the executables or modules.

section index

––––

Unpacking Archives

Source is usually distributed in compressed archives. Which makes sense, since it usually contains of more than one file and compression works especially good on text files.

In UNIX, these archives are created and expanded by using two different programs: one that collects all file in an archive ('tar') and one which does the compression. By convention, gzip compressed archives have the ending 'tar.gz' or 'tgz', whereas bzip2 compressed archives end on 'tar.bz2' or 'tbz2'. These archives are colloquially called 'tarballs'.

To expand archives, you can either use some graphical archive manager like KDE's 'Archiver' or GNOME's 'guiTAR'. In KDE and GNOME, they should be started automatically as soon as you (double-)click on an archive file in the respective file manager.
On the command line, you use:

tar xzf archive for extracting gzip-compressed tar file archives, and

tar xjf archive for tar files compressed with bzip2 (older version of tar might require 'y' instead of 'j').
The first option ('x') means 'extract'. For creating archives, you'd substitute it with 'c', to merely list the contents with 't'), the second denotes the compression utility and the 'f' tells a 'tar' to expect a filename.

"Pure" 'bzip2' or even 'zip' archives are quite rare in the Linux world. Unpack such archives with bunzip2 archive or unzip archive (the latter works on self-extracting '.exe' archives, too).

section index

––––

Important Files to Read

Most source archives contain files called README and INSTALL. They feature comments by the programmer on the program, how to compile it, things to watch out for and more. It goes without saying that you should read these files ;-), except if the INSTALL file begins with 'These are generic instructions', in this case the programmer couldn't be bothered to replace the file generated by 'autoconf' by something specific and helpful.
Like every other file in the archive you can open them with every program that is capable of displaying text files.

section index

––––

Needed Packages

Here's a checklist of packages you will need for compiling. Check with rpm -q name if these are installed.
If you have a 1-CD version of ML, some of these might not be on that CD; in this case get them via rpmfind.net .

Compiler

• gcc
• glibc-devel
• gcc-c++
• libstdc++-devel

System

• make
• kernel-headers

Popular Libraries

There are libraries which are used very often by applications. Having their development counterparts installed should get you through most compilations without errors due to missing libraries. These development libraries are the most popular with programmers. If you have them installed, you should get through most compilations without errors due to missing libraries.

• libgtk+-devel, libglib-devel (most common widget set)
• libgr-devel, libungif-devel, libjpeg-devel, libpng-devel, libtiff-devel, libxpm-devel (image formats)
• libtermcap-devel, libncurses-devel (for console applications)
• XFree86-devel (for all graphical applications)
• zlib-devel (compression library)

There are two things to note about package names for libraries:

• Older Mandrake Linux library packages might not have the 'lib' prefix, e.g. 'libgtk+-devel' was 'gtk+-devel'. * Some library packages might have a version number in their name, e.g. the actual and current name of 'libpng-devel' is 'libpng3-devel'. This isn't important, I just mention it here to avoid confusion ;-).

Now you're ready for compiling .

Related Resources:

Software Building HOWTO

––––

Comments and Questions

This page should mention what to do with Mandrake's own 'src.rpm' package. The urpmi man page does not make it clear. –– Mark Stosberg

Revision / Modified: April 21, 2002
Author: Tom Berger

Legal: This page is covered by the GNU Free Documentation License . Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.