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
thesource 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' program. This script, when run, 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.
section index top
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. One other
interesting option is 'C' which tells 'tar' to switch to another directory
before extracting the archive:
tar xzfC archive dir
"Pure" 'bzip2' or even 'zip' archives are quite rare
in the Linux world. Unpack such archives with bunzip2 archive
orunzip archive (the latter works on self-extracting
'.exe' archives, too).
section index top
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 top
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
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)
If you are compiling programs for GNOME or KDE, you
will need the '-devel-' versions of their libraries. For KDE, you will also
need 'libqt-devel'.
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 ;-).
section index top
Now you're ready for compiling.
|